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源 代码 的 重要 性 

Java 开 发 人 员 都 知道 ， 阅 读 源 码 是 一 个 非常 好 的 学 习 方式 ， 在 我 
们 日 党 工作 中 或 多 或 少 都 会 接触 一 些 开 产 代 码 ， 比 如 说 最 音 用 的 
Struts、Hibernate、Spring， 这 些 源码 的 普及 与 应 用 程度 远 远 超过 我 们 
的 想象 ， 正 因为 很 多 人 使 用 ， 也 在 推动 着 源码 不 断 地 去 完善 。 这 些 优 
秀 的 源码 中 有 着 多 年 积淀 下 来 的 精华 ， 这 些 精 华 是 非常 值得 我 们 学 习 
的 ， 不 管 我 们 当前 是 什么 水 平 ， 通 过 反复 阅读 源码 能 力 能 有 所 提升 ， 
小 到 对 源码 所 提供 的 功能 上 的 使 用 更 加 熟练 ， 大 到 使 我 们 的 程序 设计 
更 加 完美 优秀 。 但 是 ， 纵 观 我 们 身边 的 人 ， 能 够 做 到 通读 源码 的 真 的 
是 少 之 又 少 ， 究 其 原因 不 外 乎 以 下 几 点 。 

阅读 源码 绝对 算得 上 是 一 件 费时 费力 的 工作 ， 需 要 读者 耗费 大 量 
的 时 间 去 完成 。 而 作为 开发 人 员 ， 毕 竟 精 力 有 限 ， 实 在 没 办 法 拿 出 太 
多 的 时 间 放 在 源码 的 阅读 上 。 

源码 的 复杂 性 。 任 何 一 款 源码 经 历 了 多 年 的 发 展 与 提炼 ， 其 复杂 
程度 可 想 而 知 。 当 我 们 阅读 源码 的 时 候 ， 大 家 都 知道 需要 通过 工具 来 
跟踪 代码 的 运行 ， 进 而 去 分 析 程 序 。 但 是 ， 当 代码 过 于 复杂 ， 环 环 相 
扣 绕 来 绕 去 的 时 候 ， 跟 进 了 几 十 个 甚至 几 百 个 肖 数 后 ， 这 时 我 们 已 经 
不 知道 自己 所 处 的 位 置 了 ， 不 得 不 再 重 来 ， 但 是 一 次 又 一 次 的 ， 最 终 
发 现 自己 根本 无 法 驾驭 它 ， 不 得 不 放弃 。 

有 些 源码 发 展 多 年 ， 会 遇 到 各 种 各 样 的 问题 ， 并 对 问题 进行 了 解 
决 ， 而 这 些 问题 有 的 对 于 我 们 来 说 甚至 可 以 用 莫名 其 妙 来 修饰 ， 有 时 
候 根 本 想 不 出 会 在 什么 情况 下 会 发 生 。 我 们 选择 各 种 查阅 资料 ， 查 询 
FR, ABM, RAMA. 


无 论 基于 什么 样 的 原因 ， 放 弃 阅 读 源 码 始终 不 是 一 个 明智 的 选 
择 ， 因 为 你 失去 了 一 个 跟 大 师 学 习 的 机 会 。 而 且 ， 当 你 读 过 几 个 源码 
之 后 你 会 发 现 ， 他 们 的 思想 以 及 实现 方式 是 相通 的 。 这 就 是 开源 的 好 
处 。 随 着 各 种 开源 软件 的 发 展 ， 各 家 都 会 融合 别家 优秀 之 处 来 不 断 完 
善 自己 ， 这 样 ， 到 最 后 的 结果 就 是 所 有 的 开源 软件 从 设计 上 或 者 实现 
上 都 会 变 得 越 来 越 相 似 ， 也 就 是 说 当 你 读 完 某 个 优秀 源码 后 再 去 读 另 
一 个 源 代 码 ， 速 度 会 有 很 大 提升 。 

以 我 为 例 ，Spring 是 我 阅读 的 第 一 个 源码 ， 几 乎 耗 尽 了 我 将 近 半 


MyBatis 只 用 了 两 周 时 间 。 当 然 ， 暂 且 不 论 它 们 的 复杂 程度 不 同 ， 至 少 
我 阅读 的 时 候 发 现 有 很 多 相通 的 东西 。 当 你 第 一 次 阅读 的 时 候 ， 你 的 
重点 一 定 是 在 源码 的 理解 上 ， 但 是 ， 当 你 读 完 第 一 个 源码 再 去 读 下 一 
个 的 时 候 ， 你 自然 而 然 地 会 融 着 批判 或 者 说 挑剔 的 眼光 去 阅读 ; Att 
么 这 个 功能 在 我 之 前 看 的 源码 中 是 那样 实现 的 ， 而 在 这 里 会 是 这 样 实 
现 的 ? 这 其 中 的 道理 在 哪里 ， 哪 种 实现 方式 更 优秀 呢 ? 而 通过 这 样 的 
对 比 及 探索 ， 你 会 友 现 ， 目 己 的 进步 快 得 难以 想象 。 

我 们 已 经 有 些 纠结 了 ， 既 然 阅 读 源码 有 那么 多 的 好 处 ， 但 是 很 多 
同学 却 因为 时 间或 者 能 力 的 问题 而 不 得 不 放 乔 ， 岂 不 是 太 可 惜 ? 为 了 
解决 这 个 问题 ， 我 撰写 了 本 书 ， 总 结 了 自己 的 研究 心得 和 实际 项 目 经 
验 ， 和 希望 能 对 正在 Spring 道路 上 摸索 的 同仁 们 提供 一 些 帮助 。 

本 书 特 后 

本 书 完全 从 开发 者 的 角度 去 剖析 源码 ， 每 一 章 都 会 提供 具有 代表 
性 的 实例 ， 并 以 此 为 基础 进行 功能 实现 的 分 析 ， 而 不 是 采取 开篇 就 讲 
解 什么 容器 怎么 实现 、AOP 怎 么 实现 之 类 的 写法 。 在 描述 的 过 程 中 ， 
本 书 尽 可 能 地 把 问题 分 解 ， 使 用 剥 洋 苦 的 方式 一 层 一 层 地 将 逻辑 描述 
清楚 ， 帮 助 读者 由 浅 入 深 地 进行 学 习 ， 并 把 这 些 难点 和 问题 各 个 击 
破 ， 而 不 是 企图 一 下 让 读者 理解 一 个 复杂 的 逻辑 。 


在 阅读 源码 的 过 程 中 ， 我 们 难免 会 遇 到 各 种 各 样 的 生僻 功能 ， 这 
些 功 能 在 特定 的 场合 会 非常 有 用 ， 但 是 可 能 多 数 情 况 下 并 不 是 很 常 
用 ， 甚 至 都 查阅 不 到 相关 的 使 用 资料 。 本 书 中 重点 针对 这 种 情况 提供 
了 相应 的 实用 示例 ， 让 读者 更 加 全 面 地 了 解 Spring 所 提供 的 功能 ， 对 
代码 能 知 其 然 还 知 其 所 以 然 。 

本 书 按照 每 章 所 提供 的 示例 跟踪 Spring 源码 的 流程 ， 尽 可 能 保证 
代码 的 连续 性 ， 使 读者 的 思维 不 被 打 乱 ， 让 读者 看 到 Spring 的 执行 流 
程 ， 旨 在 尽量 使 读者 在 阅读 完 本 书后 即使 在 不 疝 读 Spring 源码 的 情况 
下 也 可 以 对 Spring 源码 进行 优化 ， 甚 至 通过 扩展 源码 来 满足 业务 需 
求 ， 这 对 开发 人 员 来 说 是 一 个 很 高 的 要 求 。 本 书 就 希望 能 帮助 读者 全 
面 提升 实战 能 力 。 

本 书 结构 

本 书 分 为 两 部 分 : 核心 实现 和 企业 应 用 。 

第 一 部 分 核心 实现 (9810-7288) : 是 Spring 功能 的 基础 ， 也 是 企 
业 应 用 部 分 的 基础 ， 主 要 对 容器 以 及 AOP 功 能 实现 做 了 具体 的 分 析 ， 
如 果 读 者 之 前 没有 接触 过 Spring 产 代码 ， 建 议 认 真 阅读 这 个 部 分 ， 否 
则 阅读 企业 应 用 部 分 时 会 比较 吃力 。 

第 二 部 分 企业 应 用 《第 8 一 13 章 ) : 在 核心 实现 部 分 的 基础 上 围 
绕 企 业 应 用 常用 的 模块 进行 讨论 ， 这 些 模 块 包括 Spring 整合 JDBC、 
Spring 整合 MyBatis、 事 务 、SpringMVC、 远程 服务 、Spring 消息 服务 
等 ， 旨 在 帮助 读者 在 日 常 开发 中 更 加 高 效 地 使 用 Spring。 

本 书 适 用 的 Spring 版 本 

截至 完稿 ，Spring 已 经 发 布 了 4.0.0.M1I 版 本 。 本 书 虽 然 是 基于 
Spring 3.2 版 本 编写 的 ， 但 所 讨论 的 内 容 都 属于 Spring 的 基础 和 常用 的 
功能 ， 这 些 功能 都 经 过 长 时 间 、 大 量 用 户 的 验证 ， 已 经 非常 成 熟 ， 改 
动 的 可 能 性 相对 较 小 。 而 且 从 目前 Spring 的 功能 规划 来 看 ， 本 书 所 涉 


及 的 内 容 并 不 在 Spring 未 来 改动 的 范围 内 ， 因 此 在 未 来 的 很 长 一 段 时 
间 内 本 书 都 不 会 过 时 的 。 
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Spring 是 于 2003 年 兴起 的 一 个 轻 量 级 的 Java 开 源 框架 ， 由 Rod 
Johnson 在 其 著作 《Expert One-On-One J2EE Development and Design) 
中 前 述 的 部 分 理念 和 原型 衍生 而 来 。Spring 是 为 了 解决 企业 应 用 开发 
的 复杂 性 而 创建 的 ， 它 使 用 基本 的 JavaBean 来 完成 以 前 只 可 能 由 EJB 完 
成 的 事情 。 然 而 ，Spring 的 用 途 不 仅 限 于 服务 器 端的 开发 。 从 简单 
性 、 可 测试 性 和 松 耦 合 的 角度 而 言 ， 任 何 Java 应 用 都 可 以 从 Spring 中 受 


fio 
1.1 Spring 的 整体 架构 


Spring 框 架 是 一 个 分 层 架 构 ， 它 包含 一 系列 的 功能 要 素 ， 并 被 分 
为 大 约 20 个 模块 ， 如 图 1-1 所 示 。 


图 1-1 Spring 整 体 架构 


这 些 模块 被 总 结 为 以 下 几 部 分 。 
(1) Core Container, 

Core Container (核心 容器 ) 包含 有 Core、Beans、Context 和 
Expression Language 模 块 。 

Core 和 Beans 模 块 是 框架 的 基础 部 分 ， 提 供 IoC 〈 转 控制 ) 和 依赖 
注入 特性 。 这 里 的 基础 概念 是 BeanFactory， 它 提供 对 Factory 模 式 的 经 
典 实现 来 消除 对 程序 性 单 例 模式 的 需要 ， 并 真正 地 允许 你 从 程序 逻辑 
中 分 离 出 依赖 关系 和 配置 。 

Core 模 块 主要 包含 Spring 框架 基本 的 核心 工具 类 ，Spring 的 其 他 组 
件 要 都 要 使 用 到 这 个 包 里 的 类 ，Core 模 块 是 其 他 组 件 的 基本 核心 。 当 
然 你 也 可 以 在 自己 的 应 用 系统 中 使 用 这 些 工 具 类 。 

Beans 模 块 是 所 有 应 用 都 要 用 到 的 ， 它 包含 访问 配置 文件 、 创 建 和 
管理 bean 以 及 进行 Inversion of Control / Dependency Injection (IoC/DI) 
操作 相关 的 所 有 类 。 

Context 模 块 构建 于 Core 和 Beans 模 块 基础 之 上 ， 提 供 了 一 种 类 似 
于 JNDI 注 册 器 的 框架 式 的 对 象 访问 方法 。Context 模 块 继承 了 Beans 的 
特性 ， 为 Spring 核心 提供 了 大 量 扩展 ， 添 加 了 对 国际 化 《例如 资源 绑 
定 ) 、 事 件 传播 、 资 源 加 载 和 对 Context 的 透明 创建 的 支持 。 Context 模 
块 同时 也 支持 J2EE 的 一 些 特性 ， 例 如 EJB、JMX 和 基础 的 远程 处 理 。 
ApplicationContext 接 口 是 Context 模 块 的 关键 。 

Expression Language 模块 提供 了 一 个 强大 的 表达 式 语言 用 于 在 运 
行 时 查询 和 操纵 对 象 。 它 是 JSP 2.1 规 范 中 定义 的 unifed expression 
language 的 一 个 扩展 。 该 语言 支持 设置 /获取 属性 的 值 ， 属 性 的 分 配 ， 
方法 的 调用 ， 访问 数组 上 下 文 (accessiong the context of arrays) 、 容 
器 和 索引 器 、 逻 辑 和 算术 运算 符 、 命 名 变量 以 及 从 Spring 的 IoC 容 器 中 
根据 名 称 检索 对 象 。 它 也 支持 list 投 影 、 选 择 和 一 般 的 list 聚 合 。 


(2) Data Access/Integrationo 


Data Access/Integration 层 包含 有 JDBC、ORM、OXM、JMS 和 
Transaction 模 块 ， 其 中 : 

JDBC 模 块 提供 了 一 个 JDBC 抽 象 层 ， 它 可 以 消除 见长 的 JDBC 编 码 
和 解析 数据 库 厂商 特有 的 错误 代码 。 这 个 模块 包含 了 Spring 对 JDBC 数 
He Wa eT ET AVP AR 

ORM 模 块 为 流行 的 对 象 -天 系 映 射 API， 如 JPA、JDO、 
Hibernate、iBatis 等 ， 提 供 了 一 个 交互 层 。 利 用 ORM 封 装 包 ， 可 以 混 
合 使 用 所 有 Spring 提供 的 特性 进行 O/R 映 射 。 如 前 边 提 到 的 简单 声明 性 
事物 管理 。 
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工具 ， 其 中 包括 JDO、Hibernate 和 iBatisSQL Map。 所 有 这 些 都 遵从 
Spring 的 通用 事务 和 DAO 异 常 层次 结构 。 

OXM 模 块 提供 了 一 个 对 Object/XML 了 映射 实现 的 抽象 层 ， 
Object/XML 了 映射 实现 包括 JAXB、Castor、XMLBeans、JiBX 和 
XStreamo 

JMS (Java Messaging Service) 模块 主要 包含 了 一 些 制造 和 消费 消 
息 的 特性 。 

Transaction 模块 支持 编程 和 声明 性 的 事物 管理 ， 这 些 事物 类 必须 
实现 特定 的 接口 ， 并 且 对 所 有 的 POJO 都 适用 。 

(3) Web。 

Web 上 下 文 模块 建立 在 应 用 程序 上 下 文 模块 之 上 ， 为 基于 Web 的 
应 用 程序 提供 了 上 下 文 。 所 以 ， Spring 框架 支持 与 Jakarta Struts 的 集 
成 。Web 模 块 还 简化 了 处 理 多 部 分 请 求 以 及 将 请 求 参 数 绑 定 到 域 对 象 
的 工作 。Web 层 包含 了 Web、Web-Servlet、Web-Struts 和 Web-Porlet 模 
JR, 具体 说 明 如 下 。 

Web 模 块 : 提供 了 基础 的 面向 Web 的 集成 特性 。 例 如 ， 多 文件 上 
传 、 使 用 servlet listeners 初 始 化 IoC 容 器 以 及 一 个 面向 Web 的 应 用 上 下 


文 。 它 还 包含 Spring 远程 支持 中 Web 的 相关 部 分 。 

Web-Servlet 模 块 web.servlet.jar:; 该 模块 包含 Spring 的 model-view- 
controller (MVC) 实现 。Spring 的 MVC 框 架 使 得 模型 范围 内 的 代码 和 
web forms 之 间 能 够 清楚 地 分 离开 来 ， 并 与 Spring 框架 的 其 他 特性 集成 
在 一 起 。 

Web-Struts 模 块 : 该 模块 提供 了 对 Struts 的 支持 ， 使 得 类 在 Spring 应 
用 中 能 够 与 一 个 典型 的 Struts Web 层 集成 在 一 起 。 注 意 ， 该 支持 在 
Spring 3.0 中 是 deprecated 的 。 

Web-Porlet 模 块 : 提供 了 用 于 Portlet 环 境 和 Web-Servlet 模 块 的 MVC 
的 实现 。 

(4) AOP。 

AOP 模 块 提 供 了 一 个 符合 AOP 联 盟 标准 的 面向 切面 编程 的 实现 ， 
它 让 你 可 以 定义 例如 方法 拦截 器 和 切 点 ， 从 而 将 逻辑 代码 分 开 ， 降 低 
它们 之 间 的 耦合 性 。 利 用 source-level 的 元 数据 功能 ， 还 可 以 将 各 种 行 
为 信息 合并 到 你 的 代码 中 ， 这 有 点 像 .Net 技 术 中 的 attribute 概 念 。 

通过 配置 管理 特性 ，Spring AOP 模 块 直接 将 面向 切面 的 编程 功能 
集成 到 了 Spring 框架 中 ， 所 以 可 以 很 容易 地 使 Spring 框架 管理 的 任何 对 
象 支持 AOP。Spring AOP 模 块 为 基于 Spring 的 应 用 程序 中 的 对 象 提供 
了 事务 管理 服务 。 通 过 使 用 Spring AOP， 不 用 依赖 EJB 组 件 ， 就 可 以 
将 声明 性 事务 管理 集成 到 应 用 程序 中 。 

Aspects 模 块 提供 了 对 AspectJ 的 集成 支持 。 

Instrumentation 模 块 提 供 了 class instrumentation 支 持 和 classloader 
实现 ， 使 得 可 以 在 特定 的 应 用 服务 器 上 使 用 。 

(5) Testo 
Test 模 块 支持 使 用 JUnit 和 TestNG 对 Spring 组 件 进行 测试 。 


12 环境 措 建 


Spring 已 经 将 源码 从 svn 迁 移 到 了 GitHub。 而 且 也 改 为 基于 Gradle 
的 构建 来 构建 项 目 ， 它 取代 了 之 前 的 Ant+Ivy 系 统 ， 所 以 要 构建 Spring 
源码 环境 首先 要 安装 GitHub 以 及 Gradle。 


1.2.1 GitHub 


首先 读者 需要 到 GitHub 官 网 去 下 载 安 装 包 ， 其 中 Windows 系 统 对 
应 的 版 本 下 载 地 址 为 : http://windows.github.com/， 下 载 后 双击 进行 安 
装 。 安 装 成 功 后 ， 快 捷 菜 单 中 会 出 现 GitHub 的 菜单 ， 如 图 1-2 所 示 。 


GrtHub, Inc 

© Git shell 

© GitHub online support 
© GitHub 

HP 


4 ”返回 


图 1-2 HitHub 安 装 成 功 后 的 启动 菜单 


1.2.2 Gradle 


Gradle 是 一 个 基于 Groovy 的 构建 工具 ， 它 使 用 Groovy 来 编写 构建 
脚本 ， 支 持 依赖 管理 和 多 项 目 创建 ， 类 似 Maven， 但 比 其 更 加 简单 轻 
便 。Gradle 为 Ivy 提供 了 一 个 layer， 提 供 了 build-by-convention 集成 ， 
而 且 它 还 让 你 获得 许多 类 似 Maven 的 功能 。 你 可 以 从 http://www. 
gradle.org/downloads 页 面 下 载 Gradle ， 下 载 后 将 文件 解压 放 到 指定 目 
RP (EEM T C:\Program Files 目 录 下 ) ， 然 后 开始 进行 环境 变量 
的 配置 。 


(1) 根据 对 应 目录 创建 GRADLE_ HOME 系统 变量 ， 如 图 1-3 所 
7o 


(2) 将 系统 变量 加 入 到 path 中 ， 如 图 1-4 所 示 。 


TEAN) GRADLE HOME 


图 1-3 创 建 对 应 于 Gralde 的 系统 变 


TPR =. 
Se 
qug [em| 
THe OD Path 
SRA v) WTAVA_ HOMES bin: N 
| WE 取消 


图 1-4 将 Gradle 对 应 的 系统 变量 加 入 path 中 
(3) 测试 。 
当 完 成 系统 变量 的 配置 后 打开 命令 窗口 输入 命令 “ 


ap "gradle 一 


version”， 如 果 安 装 成 功 会 出 现 Gradle 对 应 的 版 本 信息 ， 如 图 1-5 所 示 。 


C: Nisers Midministrator»gradle -version 


图 1-5 测试 Gradle 的 环境 变量 配置 


1.2.3 下 载 Spring 
因为 Spring 产 码 是 通过 GitHub 进 行 管 理 的 ， 所 以 我 们 首先 打开 
GitHub， 单 击 快捷 菜单 中 的 “Git Shell” 选 项 ， 如 图 1-6 所 示 。 


GitHub, Inc 
Q Git shell 
«9 GitHub online support 


Q GitHub 


图 1-6 启动 GitHub 启 动 菜单 


打开 GitHub 后 ， 你 可 以 通过 cd 命令 将 当前 操作 目录 转换 到 我 们 想 
要 存储 产 码 的 目录 ， 例 如 ， 想 要 将 下 载 的 源码 存储 到 e:\test 下， 则 可 以 
执行 “cd e:\test”。 

输入 以 下 命令 : 

git clone git://github.com/SpringSource/Spring-framework.git 

其 中 “git://github.com/SpringSource/Spring-framework.git” 为 Spring 
的 源码 地 址 。 执 行 命令 后 便 进入 源码 下 载 状态 ， 如 图 1-7 所 示 。 


Am > = 
ea EER: CAWindows\System32\WindowsPowerShell\v1.0\Powershell.exe S| Ba 


Mindovs PowerShe 11 
RAV ERAS <C> 2009 Microsoft Corporation. {RAAF 


C: Nisers Administrator \Desktop> cd E:\test 

E:\test> git clone git://github.com/SpringSource/spring-framework.git 
Cloning into 'spring-framewvork'... 

remote: Counting objects: 153681, done. 

remote: Compressing objects: 188» (48477/484775. done. 

Receiving objects: 1% €X1767/1536015, 476.8080 KiB i 5 KiB/s 


图 1-7 使 用 GitHub 开 始 下 载 源码 


经 过 一 段 时 间 的 等 待 后 源码 下 载 结 束 ， 窗 口 状态 如 图 1-8 所 示 。 


ey SER: C:\Windows\System32\WindowsPowerShell\v1.0\Powershell.exe ot (de) X 


Windows PowerShell 
RR 所 有 <C> 28809 Microsoft Corporation 


iC: Users Vidninistrator*Desktop? cd E:N 

E:\test> git clone git://github.com/SpringSource/spring-franmework.git 
Cloning into ’spring-framework’ ... 

remote: Counting objects: 153681, done. 

remote: Compressing objects: 188» (48477/48477), done. 

remote: Total 153601 «delta 852885, reused 149988 (delta 820935 
Receiving objects: 1880» €(1536801/153681»5, 34.801 MiB i 8 KiB/s, done. 
Resolving deltas: 188» (85208785208). done. 

Checking out files: 180» (6873/68735, done. 


E:\test> 


图 1-8 源码 下 载 结束 的 窗口 显示 


而 这 时 候 我 们 去 查看 ， 对 应 的 文件 夹 下 已 经 存在 了 相应 的 源码 信 
息 ， 如 图 1-9 所 示 。 


git e. spring-tx 
@ settings e. spring-web 
@ bulldsrc e. spring-webmvc 
e. gradle & spring-webmvc-portlet 
e. spring-aop e. spring-webmvc-tiles3 
@ spring-aspects e. spring-websocket 
@ spring-beans @ src 
@ spring-context & | -gitignore 
@ spring-context-support @) build.gradle 
e. spring-core &j | CONTRIBUTING.md 
e. spring-expression | gradle.properties 
@ spring-instrument & |gradlew 
e spring-instrument-tomcat — igradlew.bat 
e. spring-jdbc %) import-into-eclipse.bat 
e. spring-jms $9 | import-into-eclipse.sh 
@ spring-orm & | import-into-idea.md 
&. spring-orm-hibernate4 a | README.md 
@ spring-oxm $9 settings.gradle 
e. spring-test 
@ spring-test-mvc 


1-9 下 载 的 Spring 源码 


但 是 当前 的 源码 并 不 可 以 直接 导入 Eclipse 中 ， 我 们 还 需要 将 源码 
转换 为 Eclipse 可 以 读 取 的 形式 。 网 上 有 各 种 各 样 的 方法 ， 其 中 出 现 最 
多 的 是 告诉 大 家 将 所 有 工程 一 次 性 的 编译 、 导 入 ， 但 是 笔者 并 不 推荐 
这 样 的 方式 ， 因 为 这 样 会 耗费 大 量 的 时 间 ， 而 且 当 存 在 编译 错误 的 时 
候 你 不 得 不 重新 编译 。 笔 者 建议 只 对 我 们 感 兴趣 的 工程 进行 Eclipse 工 
程 转 换 ， 比 如 我 们 想 要 查看 Spring 事务 部 分 的 源码 ， 打 开 命 令 窗口 
将 当前 目录 切换 至 源码 所 在 目录 ， 例 如 ， 这 里 是 Spring tx 文件 夹 下 , 


执行 命令 “gradle cleanidea eclipse”， 当 窗口 出 现 如 下 状态 说 明 已 经 开始 
执行 转换 过 程 ， 如 图 1-10 所 示 。 


D:*stest'*spring-framevork*spring-tx»gradle cleanIdea eclipse 


:buildSrc:compileJava 
:buildSrc:compileGroouvy 
:buildSrc:processResources 


图 1-10 Spring 源码 转换 至 eclipse 工 程 


经 过 一 段 时 间 后 转换 成 功 ， 如 图 1-11 所 示 。 

这 时 ， 我 们 再 查看 对 应 的 文件 夹 会 发 现 ， 已 经 出 现 了 作为 Eclipse 
工程 所 必须 的 .project 与 .classpath 文 件 了 ， 如 图 1-12 所 示 。 

打开 Eclipse， 将 工程 导入 ， 导 入 后 如 图 1-13 所 示 。 


"*spring-tx:eclipseJdtPrepare 
:spring-tx:eclipseJdt 
"spring-tx:eclipseProJject 
*spring-tx:eclipseSettings 
"spring-tx:eclipselstComponent 
fspring-tx:eclipse 


BUILD SUCCESSFUL 


Total time: 52.511 secs 


D= \test \spring-f ramevwork\spring-tx> 


图 1-11 Spring 产 码 成 功 转换 至 eclipse 工 程 


.settings 
bin 

@ src 

(T| classpath 


3) project 


1-12 转 换 至 Eclipse 工程 后 的 Spring 源码 结构 


4 WS :pring-tx 
E src/main/Java 
(48 src/main/resources 
(8 src/test/java 
(4$ src/test/resources 
m Referenced Libraries 


& bin 


(e src 


图 1-13 导 入 Eclipse 后 的 源码 工程 


你 会 发 现 工程 名 称 前 面 有 一 个 感叹 号 ， 这 说 明 存 在 错误 。 查 看 依 
赖 包 及 工程 ， 会 看 到 当前 工程 所 依赖 的 包 已 经 完全 导入 ， 没 有 问题 ， 
工程 所 依赖 的 JAR 如 图 1-14 所 示 。 


(9 Source | E Projects | BA Libraries | “> Order and Export 


= 
—3 
av 


um 
[oa 


|! hamcrest-core-1.3jar - C\Users\Administrator\.gr) 
9 Javax.persistence-2.0.0 Jar - CAUsersVAdministrator 


|! mockito-core-1.9.5jar - C:\Users\Administrator\.g| 
| objenesis-1.0jar - C\Users\Administrator\.gradle\ 


mà JRE System Library [jdk1.5.0 07] 


JARs and class folders on the build path: 


aopalliance-1.0jJar - C\Users\Administrator\.gradl 
aspectjweaver-1.7.2Jar - CAUsersyVAdministratorl.c 
connector-api-1.5,jar - CAUsers\Administrator\.gré 
ejb-api-3.0 jar - C:\Users\Administrator\.gradle\ca 


hamcrest-all-1.3jar - C\Users\Administrator\.grac 


| 


javax.transaction-api-1.2-b03.jar - CAUsersVAdmin| 
junit-4.11 jar - C:\Users\Administrator\.gradle\cact 


uow-5.0.2.17 jar - C:\Users\Administrator\.gradle\¢ 


m ‘ D 


Edit... 


Remove 


Migrate JAR File... 


但 是 ， 查 看 依赖 的 Projects 时 发 现 ， 当 前 工程 还 要 依赖 于 其 他 


图 1-14 工程 依赖 的 JAR 


Spring 中 的 6 个 工程 ， 这 时 ， 读 者 可 以 选择 以 同样 的 方式 继续 导 
工程 ， 或 者 ， 直 接 找到 对 应 的 JAR 加 入 编译 路 径 ， 工 程 所 依赖 的 
Projects 如 图 1-15 所 示 。 


源码 


D 6 build path entries are missing. E v v 


E Source | 区 Projects E Libraries | ^ Order and Export. 


Required projects on the build path: 


ig spring-aop (missing) | Add... 
b? spring-beans (missing) 
lg? spring-context (missing) Edit... 


ig spring-core (missing) 
ig spring-expression (missing) 


b? spring-instrument (missing) 


| OK Cancel 
图 1-15 工程 所 依赖 的 Projects 


n 8 现 


源码 分 析 是 一 件 非常 煎熬 非常 有 挑战 性 的 任务 ， 你 准备 好 开始 战 
斗 了 吗 ? 

在 正式 开始 分 析 Spring 源码 之 前 ， 我 们 有 必要 先 来 回顾 一 下 
Spring 中 最 简单 的 用 法 ， 尽 管 我 相信 您 已 经 对 这 个 例子 非常 熟悉 了 。 


2.1 Z 5 


bean 是 Spring 中 最 核心 的 东西 ， 因 为 Spring 就 像 是 个 大 水 桶 ， 而 
bean 就 像 是 容器 中 的 水 ， 水 桶 脱离 了 水 便 也 没什么 用 处 了 ， 那 么 我 们 
先 看 看 bean 的 定义 。 

public class MyTestBean { 

private String testStr — "testStr"; 
public String getTestStr() 1 
return testStr; 
j 
public void setTestStr(String testStr) { 
this.testStr - testStr; 


j 

很 普通 ，bean 没 有 任何 特别 之 处 ， 的 确 ，Spring 的 目的 就 是 让 我 
们 的 bean 能 成 为 一 个 纯粹 的 POJO ， 这 也 是 Spring 所 追求 的 。 接 下 来 看 
看 配置 文件 : 

<?xml version="1.0" encoding="UTF-8"?> 

«beans xmlns-"http://www.Springframework.org/schema/beans" 


xmins:xsi-"http://www.w3.0rg/2001/XMLSchema-instance" 


xsi:schemaLocation="http://www.Springframework.org/schema/beans 
http://www. Springframework. 

org/schema/beans/Spring-beans.xsd"> 

<bean id="myTestBean" class="bean.MyTestBean"/> 


</beans> 


在 上 面 的 配置 中 我 们 看 到 了 bean 的 声明 方式 ， 尽 管 Spring 中 bean 的 
元 素 定义 着 N 种 属性 来 支撑 我 们 业务 的 各 种 应 用 ， 但 是 我 们 只 要 声明 
成 这 样 ， 基 本 上 就 已 经 可 以 满足 我 们 的 大 多 数 应 用 了 。 好 了 ， 你 可 能 
觉得 还 有 什么 ， 但 是 ， 真 没 了 ，Spring 的 入 门 示 例 到 这 里 已 经 结束 ， 
我 们 可 以 写 测试 代码 测试 了 。 

@Suppress Warnings("deprecation") 

public class BeanFactoryTest { 

@Test 
public void testSimpleLoad(){ 
BeanFactory bf = new XmlBeanFactory(new ClassPathResource 
( "beanFactory Test.xml")); 
MyTestBean bean=(MyTestBean) bf.getBean("my TestBean"); 
assertEquals("testStr",bean.getTestStr()); 
} 

} 

相信 聪明 的 读者 会 很 快 看 到 我 们 期 望 的 结果 : 在 Eclipse 中 显示 了 
Green Baro 

直接 使 用 BeanFactory 作 为 容器 对 于 Spring 的 使 用 来 说 并 不 多 见 ， 
甚至 是 甚 少 使 用 ， 因 为 在 企业 级 的 应 用 中 大 多 数 都 会 使 用 的 是 
ApplicationContext (后 续 章 节 我 们 会 介绍 它们 之 间 的 区 别 ) ， 这 里 只 
是 用 于 测试 ， 让 读者 更 快 更 好 地 分 析 Spring 的 内 部 原理 。 

OK， 我 们 又 复习 了 一 遍 Spring， 你 是 不 是 会 很 不 层 呢 ? 这 样 的 小 
例子 没 任何 挑战 性 。 嗯 ， 确 实 ， 这 样 的 使 用 是 过 于 简单 了 ， 但 是 本 书 
的 目的 并 不 是 介绍 如 何 使 用 Spring， 而 是 帮助 您 更 好 地 了 解 Spring 的 
内 部 原理 。 读 者 可 以 自己 先 想 想 ， 上 面 的 一 句 简单 代码 都 执行 了 什么 
样 的 逻辑 呢 ? 这 样 一 句 简单 代码 其 实在 Spring 中 执行 了 太 多 太 多 的 逻 


辑 ， 即 使 笔者 用 半 本 书 的 文字 也 只 能 介绍 它 的 大 致 原理 。 那 么 就 让 我 
们 快速 的 进入 分 析 状态 吧 。 


2.2 功能 分 析 


现在 我 们 可 以 来 好 好 分 析 一 下 上 面 测 试 代码 的 功能 ， 来 探索 上 面 
的 测试 代码 中 Spring 究竟 帮助 我 们 完成 了 什么 工作 ? 不 管 之 前 你 是 否 
使 用 过 Spring， 当 然 ， 你 应 该 使 用 过 的 ， 毕 竟 本 书面 用 的 是 对 Spring 有 
一 定 使 用 经 验 的 读者 ， 你 都 应 该 能 猜 出 来 ， 这 段 测 试 代 码 完成 的 功能 
无 非 就 是 以 下 几 点 。 

(1) 读 取 配置 文件 beanFactoryTest.xml。 

(2) 根据 beanFactoryTest.xml 中 的 配置 找到 对 应 的 类 的 配置 ， 并 
实例 化 。 

(3) 调用 实例 化 后 的 实例 。 

为 了 更 清楚 地 摘 述 ， 笔 者 临时 画 了 设计 类 图 ， 如 图 2-1 所 示 ， 如 果 
想 完成 我 们 预想 的 功能 ， 至 少 需 要 3 个 类 。 


ReflectionUtil | ConfigReader 
| = 


图 2-1 最 简单 的 Spring 功 能 架构 


ConfigReader: 用 于 读 取 及 验证 配置 文件 。 我 们 要 用 配置 文件 里 
面 的 东西 ， 当 然 首先 要 做 的 就 是 读 取 ， 然 后 放置 在 内 存 中 。 


ReflectionUtil: 用 于 根据 配置 文件 中 的 配置 进行 反射 实例 化 。 比 
如 在 上 例 中 beanFactoryTest.xml 出 现 的 <bean id="myTestBean" 
class="bean.MyTestBean"/>， 我 们 就 可 以 根据 bean.MyTestBean 进 行 实 
例 化 。 

App: 用 于 完成 整个 逻辑 的 串联 。 

ee 整个 过 程 无 非 如 此 ， 但 是 作为 一 个 风靡 
世界 的 优秀 源码 真 的 就 这 么 简单 吗 ? 


2.3 工程 搭建 


不 如 我 们 首先 大 致 看 看 Spring 的 源码 。 在 Spring 源码 中 ， 用 于 实 
现 上 面 功能 的 是 org.Springframework.beans.jar， 我 们 看 源码 的 时 候 要 打 
开 这 个 工程 ， 如 果 我 们 只 使 用 上 面 的 功能 ， 那 就 没有 必要 引入 Spring 
的 其 他 更 多 的 包 ， 当 然 Core 是 必须 的 ， 还 有 些 依赖 的 包 如 图 2-2 所 示 。 


e Source | iz Projects E Libraries | ¢ x Order and Export | 


JARs and class folders on the build path: 


we com.springsource.javax.el-1.0.0.jar - org.springframework.beans/lib Add JARs... 
ad com.springsource.javax.nject-1.0.0.jar - org.springframework.beans/lib 


os com.springsource.net.sf.cglib-2.2.0.jar - org.springframework.beans/lib Add External JARs 


os com.springsource.org.apache.commonsJogging-1.1.1,jar - org.springframework.beans;| Add Variable 


oe com.springsource.org.apacheog4j-1.2.16Jar - org.springframework.beans/lib 


oe com.springsource.org.easymock-2.5.1.jar - org.springframework.beans/lib Add Library... 


oe com.springsource.org.hamcrest-1.1.0jar - org.springframework.beans/lib 
a i à : Add Class Folder... 
ad com.springsource.org.junit-4.9.0.jar - org.springframework.beans/lib 


mA JRE System Library [jdk] Add External Class Folder... 


2-2 Springjlll i3 25 (ft 的 JAR 


引入 依赖 的 JAR 消除 掉 所 有 编译 错误 后 ， 终 于 可 以 看 源码 了 。 或 
许 你 已 经 知道 了 答案 ， Spring 居然 用 了 N 多 代码 实现 了 这 个 看 似 很 简 
单 的 功能 ， 那 么 这 些 代码 都 是 做 什么 用 的 呢 ? Spring 在 架构 或 者 编码 
的 时 候 又 是 如 何 考虑 的 呢 ? 市 着 疑问 ， 让 我 们 踏 上 了 研读 Spring 产 码 
的 征程 。 


2.4 Spring 的 结构 组 成 


我 们 首先 尝试 梳理 一 下 Spring 的 框架 结构 ， 从 全 局 的 角度 了 解 一 
下 Spring 的 结构 组 成 。 


时 候 或 者 说 大 多 数 时 候 会 被 复杂 的 代码 绕 来 绕 去 ， 绕 到 最 后 已 经 不 知 
道 自己 身 在 何 处 了 ， 但 是 ， 如 果 配 以 UML 还 是 可 以 搞定 的 。 笔 者 就 是 
按照 自己 的 思路 进行 分 析 ， 并 配合 必要 的 UML ， 和 希望 读者 同样 可 以 跟 
得 上 思路 。 

我 们 先 看 看 整个 beans 工 程 的 源码 结构 ， 如 图 2-3 所 示 。 


4 \> org.springtramework.beans 


“8 src/main/java 
G src/main/resources 
$ src/test/Java 
(8 src/test/resources 
má JRE System Library [jdk] 
mA Referenced Libraries 
( lib 
i src 

beans.iml 
$) build.xml 
X; ivyxml 
m) pom.xml 


template.mf 


图 2-3 beans 工 程 的 源码 结构 


beans 包 中 的 各 个 源码 包 的 功能 如 下 。 
src/main/java 用 于 展现 Spring 的 主要 逻辑 。 
src/main/resources 用 于 存放 系统 的 配置 文件 。 
src/test/java 用 于 对 主要 逻辑 进行 单元 测试 。 
src/test/resources 用 于 存放 测试 用 的 配置 文件 。 


通过 beans 工 程 的 结构 介绍 ， 我 们 现在 对 beans 的 工程 结构 有 了 初 
步 的 认识 ， 但 是 在 正式 开始 源码 分 析 之 前 ， 有 必要 了 解 一 下 Spring 中 
最 核心 的 两 个 类 。 

1. DefaultListableBeanFactory 

XmlBeanFactory447K Bj DefaultListableBeanFactory, M 
DefaultListableBeanFactory 是 整个 bean 加 载 的 核心 部 分 ， 是 Spring 注册 
及 加 载 bean 的 默认 实现 ， 而 对 于 XmlBeanFactory 与 


DefaultListableBeanFactory 不 同 的 地 方 其 实 是 在 XmlBeanFactory 中 使 
用 了 自 定义 的 XML 读 取 器 XmlBeanDefinitionReader， 实 现 了 个 性 化 的 
BeanDefinitionReader 读 取 ，DefaultListableBeanFactory 继 承 了 
AbstractAutowireCapableBeanFactory 并 实现 了 
ConfigurableListableBeanFactory 以 及 BeanDefinitionRegistry 接 口 。 以 下 
是 ConfigurableListableBeanFactory 的 层次 结构 图 ( 见 图 2-4) 以 及 相关 
类 图 ( 见 图 2-5) 。 

从 上 面 的 类 图 以 及 层次 结构 图 中 ， 我 们 可 以 很 清晰 地 从 全 局 角度 
了 解 DefaultListableBean Factory 的 脉络 。 如 果 读 者 没有 了 解 过 Spring 源 
码 可 能 对 上 面 的 类 图 不 是 很 理解 ， 不 过 没关系 ， 通 过 后 续 的 学 习 ， 你 
会 逐渐 了 解 每 个 类 的 作用 。 那 么 ， 让 我 们 先 简单 地 了 解 一 下 上 面 类 图 
中 的 各 个 类 的 作用 。 

AliasRegistry: 定义 对 alias 的 简单 增删 改 等 操作 。 

SimpleAliasRegistry: 主要 使 用 map 作 为 alias 的 缓存， 并 对 接口 
AliasRegistry 进 行 实现 。 

SingletonBeanRegistry: 定义 对 单 例 的 注册 及 获取 。 

BeanFactory: 定义 获取 bean 及 bean 的 各 种 属性 。 

DefaultSingletonBeanRegistry: XH SingletonBeanRegistryS Kl 
数 的 实现 。 

HierarchicalBeanFactory: 继承 BeanFactory， 也 就 是 在 BeanFactory 
定义 的 功能 的 基础 上 增加 了 对 parentFactory 的 支持 。 

BeanDefinitionRegistry: 定义 对 BeanDefinition 的 各 种 增删 改 操 
作 。 

FactoryBeanRegistrySupport: 在 DefaultSingletonBeanRegistry 基 础 
上 增加 了 对 FactoryBean 的 特殊 处 理 功能 。 


efaultListableB eanFactory - org.springframework.beans.factory.support 
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Q AliasRegistry 
© SingletonBeanRegistry 
4 © ConfigurableBeanFactory 
4 © HierarchicalBeanFactory 
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Q singletonBeanRegistry 
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2-4 ConfigurableListableBeanFactory 的 层次 结构 图 
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图 2-5 容器 加 载 相 关 类 图 


Pljava Interface» 
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ConfigurableBeanFactory: 提供 配置 Factory 的 各 种 方法 。 


ListableBeanFactory: 根据 各 种 条 件 获取 bean 的 配置 清单 。 
AbstractBeanFactory: 综合 FactoryBeanRegistrySupport 和 


ConfigurableBeanFactory 的 功能 。 


AutowireCapableBeanFactory: 提供 创建 bean、 和 上 自动 注入 、 初 始 化 
以 及 应 用 bean 的 后 处 理 器 。 

AbstractAutowireCapableBeanFactory: 综合 AbstractBeanFactory 并 
对 接口 Autowire Capable BeanFactory 进 行 实 现 。 

ConfigurableListableBeanFactory: BeanFactory 配 置 清 单 JEA 
略 类 型 及 接口 等 。 

DefaultListableBeanFactory: 综合 上 面 所 有 功能 ， 主 要 是 对 Bean 注 
册 后 的 处 理 。 

XmlBeanFactory 对 DefaultListableBeanFactory 类 进行 了 扩展 ， 主 要 
用 于 从 XML 文档 中 读 取 BeanDefinition ， 对 于 注册 及 获取 Bean 都 是 使 用 
从 父 类 DefaultListableBeanFactory 继 承 的 方法 去 实现 ， 而 唯 独 与 父 类 不 
同 的 个 性 化 实现 就 是 增加 了 XmlBeanDefinitionReader 类 型 的 reader 属 
性 。 在 XmlBeanFactory 中 主要 使 用 reader 属 性 对 资源 文件 进行 读 取 和 注 
册 。 

2. XmlBeanDefinitionReader 

XML 配置 文件 的 读 取 是 Spring 中 重要 的 功能 ， 因 为 Spring 的 大 部 
分 功能 都 是 以 配置 作为 切入 点 的 ， 那 么 我 们 可 以 从 
XmlBeanDefinitionReader 中 梳理 一 下 资源 文件 读 取 、 解 析 及 注册 的 大 
致 脉络 ， Sees ae HEo 

ResourceLoader: 定义 资源 加 载 器 ， 主 要 应 用 于 根据 给 定 的 资源 
E X. Resourceo 

BeanDefinitionReader: 主要 定义 资产 文件 读 取 并 转换 为 
BeanDefinition 的 各 个 功能 。 

EnvironmentCapable: 定义 获取 Environment 方 法 。 

DocumentLoader: 定义 从 资源 文件 加 载 到 转换 为 Document 的 功 
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AbstractBeanDefinitionReader: 对 EnvironmentCapable、 
BeanDefinitionReader 类 定义 的 功能 进行 实现 。 

BeanDefinitionDocumentReader: 定义 读 取 Docuemnt 并 注册 
BeanDefinition 功 能 。 

| : 定义 解析 Element 的 各 种 方法 。 

经 过 以 上 分 析 ， 我 们 可 以 梳理 出 整个 XML 配置 文件 读 取 的 大 致 流 

程 ， 如 图 2-6 所 示 ， 在 XmlBeanDifinitionReader 中 主要 包含 以 下 几 步 的 
处 理 。 


2 «Java Class» 加 «Java Class» 


© XmiBeanDefinitionReader © DefaultBeanDefinitionDoc ument Reader 
«uge» 
ni 
7] «Java Interface a «Java Class» a «Java Interface» a «Java Class» 
Q DocumentLoader (3 AbstractBeanDefinitionReader © BeanDefinitionDocumentReader © BeanDefinitionParserDelegate 
] ] 
Java Interf. 7l Java Interface» Java Interf 
© ResourceLoade BeanDefinitionReader O EnvironmentCapable 


图 2-6 配置 文件 读 取 相 天 类 图 


(1) 通过 继承 自 AbstractBeanDefinitionReader 中 的 方法 ， 来 使 用 
ResourLoader 将 资源 文件 路 径 转 换 为 对 应 的 Resource 文 件 。 

(2) 通过 DocumentLoader 对 Resource 文 件 进 行 转换 ， 将 Resource 
Mdb a eh 

(3) 通过 实现 接口 BeanDefinitionDocumentReader 的 
ee Wauy eae HAT HEAT, FEB 
BeanDefinitionParserDelegate 对 Element 进 行 解析 。 


2.5 容器 的 基础 XmlBeanFactory 


好 了 ， 到 这 里 我 们 已 经 对 Spring 的 容器 功能 有 了 一 个 大 致 的 了 
解 ， 尽 管 你 可 能 还 很 迷糊 ， 但 是 不 要 紧 ， 接 下 来 我 们 会 详细 探索 每 个 
步骤 的 实现 。 再 次 重申 一 下 代码 ， 我 们 接 下 来 要 深入 分 析 以 下 功能 的 
代码 实现 : 

BeanFactory bf = new XmlBeanFactory(new 
ClassPathResource("beanFactory est.xml")); 

通过 XmlBeanFactory 初 始 化 时 序 图 (如 图 2-7 所 示 ) 我 们 来 看 一 看 
上 面 代码 的 执行 逻辑 。 


bf:BeanFactoryTest classPathResource.ClassPathResource xmiBeanFactory XmlBeanFactory reader XmlBeanDefinitionReader 


1 new ClassPathResource(*beanFactoryTest xml") 
ww 


2 resource Resource 


3: new XmlBeanFactory(resource) 
wm 3.1: loadBeanDefinitions{resource) 
> 


3.2: loadedBeanDefinitionNum:int 


2-7 XmlBeanFactory 初 始 化 时 序 图 


时 序 图 从 BeanFactoryTest 测 试 类 开始 ， 通 过 时 序 图 我 们 可 以 一 目 
了 然 地 看 到 整个 逻辑 处 理 顺 序 。 在 测试 的 BeanFactoryTest 中 首先 调用 
ClassPathResource 的 构造 水 数 来 构造 Resource 资 源 文 件 的 实例 对 象 ， 这 
样 后 续 的 资源 处 理 就 可 以 用 Resource 提 供 的 各 种 服务 来 操作 了 ， 当 我 


们 有 了 Resource 后 就 可 以 进行 XmlBeanFactory 的 初始 化 了 。 那 么 
Resource 资 源 是 如 何 封装 的 呢 ? 


2.5.1 配置 文件 封装 


Spring 的 配置 文件 读 取 是 通过 ClassPathResource 进 行 封 狼 的 ， 如 
new ClassPathResource ("beanFactoryTest.xml")， 那 么 ClassPathResource 
完成 了 什么 功能 呢 ? 

在 Java 中 ， 将 不 同 来源 的 资源 抽象 成 URL， 通辽 注册 个 同 的 
handler (URLStreamHandler) 来 处 理 不 同 来 源 的 资源 的 读 取 逻 辑 ， 一 
般 handler 的 类 型 使 用 不 同 前 缀 (IM, Protocol) 来 识别 ， 如 “file:”、 
“http:” “jar:” 等 ， 然 而 URL 没有 默认 定义 相对 Classpath 或 
ServletContext 等 资源 的 handler， 虽 然 可 以 注册 自己 的 
URLStreamHandler 来 解析 特定 的 URL 前 缀 《协议 ) ， 比 如 
“classpath:”， 然 而 这 需要 了 解 UREL 的 实现 机 制 ， 而 且 URL 也 没有 提供 
一 些 基本 的 方法 ， 如 检查 当前 资源 是 否 存在 、 检 查 当 前 资源 是 否 可 读 
等 方法 。 因 而 Spring 对 其 内 部 使 用 到 的 资产 实现 了 目 己 的 抽象 结构 : 
Resource 接 口 来 封装 底层 资源 

public interface InputStreamSource { 

InputStream getInputStream() throws IOException; 

j 

public interface Resource extends InputStreamSource 1 

boolean exists(); 

boolean isReadable(); 

boolean isOpen(); 

URL getURL() throws IOException; 
URI getURI() throws IOException; 
File getFile() throws IOException; 


long lastModified() throws IOException; 

Resource createRelative(String relativePath) throws IOException; 
String getFilename(); 

String getDescription(); 

} 

InputStreamSource 封 装 任 何 能 返回 InputStream 的 类 ， 比 如 File、 
Classpath 下 的 资源 和 Byte Array 等 。 它 只 有 一 个 方 法 定义 : 
getInputStream()， 该 方法 返回 一 个 新 的 InputStream 对 象 。 

Resource 接 口 抽 象 了 所 有 Spring 内 部 使 用 到 的 底层 资源 : File、 
URL、Classpath 等 。 首 先 ， 它 定义 了 3 个 判断 当 前 资源 状态 的 方法 : 存 
在 性 (exists) 、 可 读 性 (isReadable) 、 是 否 处 于 打开 状态 

(isOpen) 。 另 外 ，Resource 接 口 还 提供 了 不 同 资源 到 URL、URI、 
File 类 型 的 转换 ， 以 及 获取 lastModified 属 性 、 文 件 名 (不 带路 径 信 息 
的 文件 名 ，getFilename()) 的 方法 。 为 了 便于 操作 ，Resource 还 提供 
了 基于 当前 资源 创建 一 个 相对 资源 的 方法 : createRelative()。 在 错误 处 
理 中 需要 详细 地 打印 出 错 的 资源 文件 ， 因 而 Resource 还 提供 了 
getDescription() 方 法 用 于 在 错误 处 理 中 的 打印 信息 。 

对 不 同 来 源 的 资源 文件 都 有 相应 的 Resource 实 现 : 文件 

(FileSystemResource) 、Classpath 资 源 (ClassPathResource) 、URL 
资源 (UrlResource) 、InputStream 资 源 (InputStreamResource) 、 

Byte 数 组 (ByteArrayResource) 等 。 相 关 类 图 如 2-8 所 示 。 
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图 2-8 资源 文件 处 理 相 关 类 图 


在 日 常 的 开发 工作 中 ， 资 源 文件 的 加 载 也 是 经 常用 到 的 ， 可 以 直 
接 使 用 Spring 提 供 的 类 ， 比 如 在 希望 加 载 文件 时 可 以 使 用 以 下 代码 : 
Resource resource=new ClassPathResource(“beanFactoryTest.xml”); 
InputStream inputStream-resource.getInputStream(); 
得 到 inputStream 后 ， 我 们 就 可 以 按照 以 前 的 开发 方式 进行 实现 
， 并 且 我 们 已 经 可 以 利用 Resource 及 其 子 类 为 我 们 提供 好 的 诸多 特 
性 。 


有 了 Resource 接 口 便 可 以 对 所 有 资源 文件 进行 统一 处 理 。 至 于 实 
现 ， 其 实 是 非常 简单 的 ， 以 getInputStream 为 例 ，ClassPathResource 中 
的 实现 方式 便 是 通过 class 或 者 classLoader 提 供 的 底层 方法 进行 调用 ， 
而 对 于 FileSystemResource 的 实现 其 实 更 简单 ， 直 接 使 用 
FileInputStream 对 文件 进行 实例 化 。 

ClassPathResource.java 

if (this.clazz != null) { 

is = this.clazz.getResourceAsStream(this.path); 
jelse 1 
is = this.classLoader.getResourceAsStream(this.path); 

} 

FileSystemResource.java 

public InputStream getInputStream() throws IOException 1 

return new FileInputStream(this.file); 

} 

当 通 过 Resource 相 关 类 完成 了 对 配置 文件 进行 封装 后 配置 文件 的 
读 取 工作 就 全 权 交 给 XmlBeanDefinitionReader 来 处 理 了 。 

了 解 了 Spring 中 将 配置 文件 封装 为 Resource 类 型 的 实例 方法 后 ， 
我 们 就 可 以 继续 探寻 XmlBeanFactory 的 初始 化 过 程 了 ， 
XmlBeanFactory 的 初始 化 有 若干 办 法 ，Spring 中 提供 了 很 多 的 构造 水 
数 ， 在 这 里 分 析 的 是 使 用 Resource 实 例 作为 构造 轴 数 参数 的 办 法 ， 代 
码 如 下 : 

XmlBeanFactory.java 

public XmlBeanFactory(Resource resource) throws BeansException { 

// 调 用 XmlBeanFactory (Resource,BeanFactory) 构造 方法 ， 


this(resource, null); 


构造 函数 内 部 再 次 调用 内 部 构造 水 数 : 
/parentBeanFactory 为 父 类 BeanFactory 用 于 factory 合 并 ， 可 以 为 空 
public XmlBeanFactory(Resource resource, BeanFactory 
parentBeanFactory) throws 
BeansException 1 
super(parentBeanFactory); 
this.reader.loadBeanDefinitions(resource); 
j 
-EreRZX FR Bf Bthis.reader.loadBeanDefinitions(resource) 才 是 资 
源 加 载 的 真正 实现 ， 也 是 我 们 分 析 的 重点 之 一 。 我 们 可 以 看 到 时 序 图 
中 提 到 的 XmlBeanDefinitionReader 加 载 数据 就 是 在 这 里 完成 的 ， 但 是 
在 XmlBeanDefinitionReader 加 载 数据 前 还 有 一 个 调用 父 类 构造 函数 初 
始 化 的 过 程 : super(parentBeanFactory)， 跟 踪 代 码 到 父 类 
AbstractAutowireCapableBeanFactoryB $338 EKZ Fia : 
AbstractAutowireCapableBeanFactory.java 
public AbstractAutowireCapableBeanFactory() 1 
super(); 
ignoreDependencyInterface(BeanNameAware.class); 
ignoreDependencyInterface(BeanFactory Aware.class); 


ignoreDependencyInterface(BeanClassLoaderAware.class); 


xX FE MEtER— FignoreDependencyInterface77 7c 
ignoreDependencyInterface 的 主要 功能 是 忽略 给 定 接口 的 自动 装配 功 
能 ， 那 么 ， 这 样 做 的 目的 是 什么 呢 ? 会 产生 什么 样 的 效果 呢 ? 

举例 来 说 ， 当 A 中 有 属性 B， 那 么 当 Spring 在 获取 A 的 Bean 的 时 候 
如 果 其 属性 B 还 没有 初始 化 ， 那 么 Spring 会 自动 初始 化 B， 这 也 是 
Spring 中 提供 的 一 个 重要 特性 。 但 是 ， 某 些 情况 下 ，B 不 会 被 初始 化 ， 


其 中 的 一 种 情况 就 是 B 实 现 了 BeanNameAware 接 口 。Spring 中 是 这 样 介 
绍 的 : 自动 装配 时 忽略 给 定 的 依赖 接口 ， 典 型 应 用 是 通过 其 他 方式 解 
析 Application 上 下 文 注册 依赖 ， 类 似 于 BeanFactory 通过 
BeanFactoryAware 进行 注入 或 者 ApplicationContext 通过 
ApplicationContextAware 进 行 注入 。 


2.5.2 Bean 
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XmlBeanDefinitionReader 类 型 的 reader 属 性 提供 的 方法 
this.readerloadBeanDefinitions(resource)， 而 这 名 代码 则 是 整个 资产 加 
载 的 切入 点 ， 我 们 先 来 看 看 这 个 方法 的 时 序 图 ， 如 图 2-9 所 示 。 


xmlBeanFactory XmlBeanFactory reader XmlBeanDefinibonReader encodedResource EncodedResource resource Resource inputScurceInputSource 
1: loadBeanDefinitions(resource) x 
LE i: pe. 11 new EncodedResource(resource) 


- 
12: encodedResource EncodedResource 


13: loadBea pem rtions(encodedResoun 
131: pner 
~ 


13.2; resource Re: 
133 vec E 
134 inputStream InputStream 
135 mew InputSource(inputStream 


13 6 inputScurceInputSource 


137. doLoadBeanDefinitions((inputSource, encodedResource getResource())) 
cA 


13 8| lopdedBeanDefinitionNum int 


14 loadedBeanDefinibonNum:int 
2: loadedBeanDefinitionNum int 


图 2-9 loadBeanDefinitionsEK 25:4 47 EJ e E] 


到 图 2-9 我 们 才 知 道 什 么 叫 山 路 十 八 弯 ， 绕 了 这 么 半天 还 没有 真 
正 地 切入 正题 ， 比 如 加 载 XML 文 档 和 解析 注册 Bean， 一 直 还 在 做 准备 
工作 。 我 们 根据 上 面 的 时 序 图 来 分 析 一 下 这 里 究竟 在 准备 什么 ”从 上 
面 的 时 序 图 中 我 们 尝试 梳理 整个 的 处 理 过 程 如 下 。 
(1) 封装 资源 文件 。 当 进入 XmlBeanDefinitionReader 后 首先 对 
参数 Resource 使 用 EncodedResource 类 进行 封装 。 
(2) 获取 输入 流 。 从 Resource 中 获取 对 应 的 InputStream 并 构造 
xus 
(3) 通过 构造 的 mputSource 实 例 和 Resource 实 例 继续 调用 函数 
doLoadBeanDefinitionso 
3X1 ]3&— FloadBeanDefinitionsEE| 2X EL US BS SC IER : 
public int loadBeanDefinitions(Resource resource) throws 
BeanDefinitionStoreException 1 
return loadBeanDefinitions(new EncodedResource(resource)); 
j 
那么 EncodedResource 的 作用 是 什么 呢 ? 通过 名 称 ， 我 们 可 以 大 致 
推断 这 个 类 主要 是 用 于 对 资源 文件 的 编码 进行 处 理 的 。 其 中 的 主要 逻 
辑 体现 在 getReader() 方 法 中 ， 当 设置 了 编码 属性 的 时 候 Spring 会 使 用 相 
应 的 编码 作为 输入 流 的 编码 。 
public Reader getReader() throws IOException { 
if (this.encoding != null) { 
return new InputStreamReader(this.resource.getInputStream(), 
this.encoding); 
j 
else { 


return new InputStreamReader(this.resource.getInputStream()); 


j 
上 面 代码 构造 了 一 个 有 编码 (encoding) 的 InputStreamReader。 当 
构造 好 encodedResource 对 象 后 ， 再 次 转 入 了 可 复 用 方法 
loadBeanDefinitions(new EncodedResource(resource))o 
这 个 方法 内 部 才 是 真正 的 数据 准备 阶段 ， 也 就 是 时 序 图 所 描述 的 
逻辑 : 
public int loadBeanDefinitions(EncodedResource encodedResource) 
throws BeanDefinitionStoreException { 
Assert.notNull(encodedResource, "EncodedResource must not be 
null"); 
if (logger.isInfoEnabled()) 1 
logger.info("Loading XML bean definitions from " + 
encodedResource. getResource()); 
} 
/通过 属性 来 记录 已 经 加 载 的 资源 
Set<EncodedResource> currentResources = 
this.resourcesCurrently BeingLoaded.get(); 
if (currentResources == null) { 
currentResources = new HashSet<EncodedResource>(4); 
this.resourcesCurrentl yBeingLoaded.set(currentResources); 
j 
if (!currentResources.add(encodedResource)) { 
throw new BeanDefinitionStoreException( 
"Detected cyclic loading of " + encodedResource + " - check 
your 


import definitions!"); 


try { 
// 从 encodedResource 中 获取 已 经 封装 的 Resource 对 象 并 再 次 从 
Resource 中 获取 其 中 的 inputStream 
InputStream inputStream = 
encodedResource.getResource().getInputStream(); 
try { 
/InputSource 这 个 类 并 不 来 自 于 Spring， 它 的 全 路 径 是 
org.xml.sax.InputSource 
InputSource inputSource = new InputSource(inputStream); 
if (encodedResource.getEncoding() != null) 1 
inputSource.setEncoding(encodedResource.getEncoding()); 
} 
/真正 进入 了 逻辑 核心 部 分 
returndoLoadBeanDefinitions(inputSource, 
encodedResource.getResource()); 
} 
finally { 
// 天 闭 输 入 流 


inputStream.close(); 


} 
catch (IOException ex) { 
throw new BeanDefinitionStoreException( 
"IOException parsing XML document from " + 
encodedResource.getResource(), ex); 
} 
finally { 


currentResources.remove(encodedResource); 
if (currentResources.isEmpty()) 1 


this.resourcesCurrentlyBeingLoaded.remove(); 


j 
我 们 再 次 整理 一 下 数据 准备 阶段 的 逻辑 ， 首 先 对 传 入 的 resource 参 
数 做 封装 ， 目 的 是 考虑 到 Resource 可 能 存在 编码 要 求 的 情况 ， 其 次 ， 
通过 SAX 读 取 XML 文 件 的 方式 来 准备 mputSource 对 象 ， 最 后 将 准备 的 
数据 通过 参数 传 入 真正 的 核心 处 理 部 分 
doLoadBeanDefinitions(inputSource, encodedResource.getResource())o 
protected int doLoadBeanDefinitions(InputSource inputSource, 
Resource resource) 
throws BeanDefinitionStoreException { 
try { 
int validationMode - getValidationModeForResource(resource); 
Document doc = this.documentLoader.loadDocument( 
inputSource, getEntityResolver(), this.errorHandler, 
validationMode, 
isNamespaceAware()); 
return registerBeanDefinitions(doc, resource); 
j 
catch (BeanDefinitionStoreException ex) { 
throw ex; 
j 
catch (SA XParseException ex) 1 


throw new 
XmlBeanDefinitionStoreException(resource.getDescription(), 
"Line " + ex.getLineNumber() + " in XML document from " + 
resource 
+" is invalid", ex); 
j 
catch (SA XException ex) 1 
throw new 
XmlBeanDefinitionStoreException(resource.getDescription(), 
"XML document from " + resource + " is invalid", ex); 
i 
catch (ParserConfigurationException ex) { 
throw new 
BeanDefinitionStoreException(resource.getDescription(), 
"Parser configuration exception parsing XML from " + resource, 
ex); 
j 
catch (IOException ex) 1 
throw new 
BeanDefinitionStoreException(resource.getDescription(), 
"IOException parsing XML document from " + resource, ex); 
} 
catch (Throwable ex) { 
throw new 
BeanDefinitionStoreException(resource.getDescription(), 
"Unexpected exception parsing XML document from " + 


resource, ex); 


} 

在 上 面 元 长 的 代码 中 假如 不 考虑 异常 类 的 代码 ， 其 实 只 做 了 三 件 
事 ， 这 三 件 事 的 每 一 件 都 必 不 可 少 。 

(1) 获取 对 XML 文件 的 验证 模式 。 

(2) 加 载 XML 文 件 ， 并 得 到 对 应 的 Document。 

(3) 根据 返回 的 Document 注 册 Bean 信 息 。 

这 3 个 步骤 支撑 着 整个 Spring 容器 部 分 的 实现 基础 ， 尤 其 是 第 3 步 
对 配置 文件 的 解析 ， 逻 辑 非 党 的 复杂 ， 那 么 我 们 先 从 获取 XML 文件 的 
验证 模式 开始 讲 起 。 


^i 


2.6 ML I 


了 解 XML 文 件 的 读者 都 应 该 知道 XML 文件 的 验证 模式 保证 了 
XML 文件 的 正确 性 ， 而 比较 常用 的 验证 模式 有 两 种 : DIDAIXSD. € 
们 之 间 什 么 区 别 呢 ? 


2.6.1 DTD 与 XSD 区 别 


DTD (Document Type Definition) 即 文档 类 型 定义 ， 是 一 种 XML 
约束 模式 语言 ， 是 XML 文件 的 验证 机 制 ， 属 于 XML 文件 组 成 的 一 部 
分 。DTD 是 一 种 保证 XML 文档 格式 正确 的 有 效 方法 ， dedu 
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确 。 一 个 DTD 文档 包含 : 元 素 的 定义 规则 ， oe 
则 ， 元 素 可 使 用 的 属性 ， 可 使 用 的 实体 或 符号 规则 。 

要 使 用 DTD 验 证 模式 的 时 候 需要 在 XML 文件 的 头 部 声明 ， 以 下 是 
在 Spring 中 使 用 DTD 声 明 方 式 的 代码 : 


<?xml version="1.0" encoding="UTF-8"?> 


«IDOCTYPE beans PUBLIC "-//Spring//DTD BEAN 2.0//EN" 
"http://www. Springframework. org/dtd/ 

Spring-beans-2.0.dtd"> 

<beans> 

</beans> 

而 以 Spring 为 例 ， 有 具体 的 Spring-beans-2.0.dtd 部 分 如 下 : 

<!ELEMENT beans ( 

description?, 
(import | alias | bean)* 

)> 

<!ATTLIST beans default-lazy-init (true | false) "false"> 

<!ATTLIST beans default-merge (true | false) "false"> 

<!ATTLIST beans default-autowire (no | byName | byType | 
constructor | autodetect) "no"> 

<!ATTLIST beans default-dependency-check (none | objects | simple | 
all) "none"> 

<!ATTLIST beans default-init-method CDATA #IMPLIED> 

<!ATTLIST beans default-destroy-method CDATA #IMPLIED> 

XML Schema 语言 就 是 XSD (XML Schemas Definition) o XML 
Schema 描述 了 XML 文档 的 结构 。 可 以 用 一 个 指定 的 XML Schema 来 验 
证 某 个 XML 文档 ， 以 检查 该 XML 文档 是 否 符合 其 要 求 。 文 档 设计 者 可 
以 通过 XML Schema 指定 一 个 XML 文档 所 允许 的 结构 和 内 容 ， 并 可 据 
此 检查 一 个 XML 文档 是 否 是 有 效 的 。XML Schema 本 身 是 一 个 XML 文 
档 ， 它 符合 XML 语法 结构 。 可 以 用 通用 的 XML 解析 器 解析 它 。 


在 使 用 XML Schema 文档 对 XML 实例 文档 进行 检验 ， 除 了 要 声明 
名 称 空间 外 (xmlns= http:/www.Springframework.org/schema/beans) , 
还 必须 指定 该 名 称 空间 所 对 应 的 XML Schema 文档 的 存储 位 置 。 通 过 
schemaLocation 属 性 来 指定 名 称 空间 所 对 应 的 XML Schema 文档 的 存储 
位 置 ， 它 包含 两 个 部 分 ， 一 部 分 是 名 称 空 间 的 URI， 另 一 部 分 就 是 该 
名 称 空间 所 标识 的 XML Schema 文件 位 置 或 URL 地 址 

(xsi:schemaLocation="http://www.Springframework.org/schema/beans 

http://www. Springframework.org/schema/beans/Spring-beans.xsd) o 

<?xml version="1.0" encoding="UTF-8"?> 

«beans xmlns-"http://www.Springframework.org/schema/beans" 


xmins:xsi-"http://www.w3.0rg/2001/XMLSchema-instance" 


xsi:schemaLocation-"http://www.Springframework.org/schema/beans 
http://www. Springframework.org/schema/beans/Spring- 
beans.xsd"> 
</beans> 
Spring-beans-3.0.xsd 部 分 代码 如 下 : 
<?xml version="1.0" encoding="UTF-8" standalone="no"?> 
«xsd:schema xmlns="http://www.Springframework.org/schema/beans" 


xmins:xsd="http://www.w3.org/2001/XMLSchema" 


targetNamespace="http://www.Springframework.org/schema/beans"> 
<xsd:import 

namespace="http://www.w3.org/X ML/1998/namespace"/> 
<xsd:annotation> 


<xsd:documentation><![CDATA[ 


eee cee 


]|></xsd:documentation> 
</xsd:annotation> 
<!-- base types --> 
<xsd:complexType name="identifiedType" abstract="true"> 
<xsd:annotation> 
<xsd:documentation><![CDATA|[ 
The unique identifier for a bean. The scope of the identifier 
is the enclosing bean factory. 
]|»«/xsd:documentation? 
</xsd:annotation> 
<xsd:attribute name="id" type="xsd:ID"> 
<xsd:annotation> 
<xsd:documentation><![CDATA[ 
The unique identifier for a bean. 
]]></xsd:documentation> 
</xsd:annotation> 
</xsd:attribute> 
</xsd:complexType> 


</xsd:schema> 


我 们 只 是 简单 地 介绍 一 下 XML 文件 的 验证 模式 的 相关 知识 ， 目 的 


在 于 让 读者 对 后 续 知 识 的 理解 能 有 连续 性 ， 如 果 对 XML 有 兴趣 的 读者 
可 以 进一步 查阅 相关 资料 。 


s 


2.6.2 Ej 


了 解 了 DTD 与 XSD 的 区 别 后 我 们 再 去 分 析 Spring 中 对 于 验证 模式 
的 提取 就 更 容易 理解 了 。 通 过 之 前 的 分 析 我 们 锁定 了 Spring 通过 
getValidationModeForResource 方 法 来 获取 对 应 资源 的 的 验证 模式 。 
protected int getValidationModeForResource(Resource resource) 1 
int validationModeToUse = getValidationMode(); 
/如 果 手 动 指定 了 验证 模式 则 使 用 指定 的 验证 模式 
if (validationModeToUse != VALIDATION AUTO) { 
return validationModeToUse; 
j 
/如 果 未 指定 则 使 用 自动 检测 
int detectedMode = detectValidationMode(resource); 
if (detectedMode != VALIDATION AUTO) { 
return detectedMode; 
j 
return VALIDATION XSD; 
j 
方法 的 实现 其 实 还 是 很 简单 的 ， 无 非 是 如 果 设 定 了 验证 模式 则 使 
用 设 定 的 验证 模式 (可 以 通过 对 调用 XmlBeanDefinitionReader 中 的 
setValidationMode 方 法 进行 设 定 ) ， 否 则 使 用 自动 检测 的 方式 。 而 自 
动 检测 验证 模式 的 功能 是 在 图 数 detectValidationMode 方 法 中 实现 的 ， 
在 detectValidationMode 孙 数 中 又 将 自动 检测 验证 模式 的 工作 委托 给 了 
专门 处 理 类 XmlValidationMode Detector， 调 用 了 
XmlvalidationModeDetector 的 validationModeDetector 方 法 ， 有 具体 代码 如 
D 
protected int detectValidationMode(Resource resource) 1 
if (resource.isOpen()) 1 


throw new BeanDefinitionStoreException( 


"Passed-in Resource [" + resource + "] contains an open stream: " 


"cannot determine validation mode automatically. Either pass in 
a Resource " * 
"that is able to create fresh streams, or explicitly specify the 
validationMode " + 
"on your XmlBeanDefinitionReader instance."); 
} 
InputStream inputStream; 
try { 
inputStream = resource.getInputStream(); 
} 
catch (IOException ex) { 
throw new BeanDefinitionStoreException( 
"Unable to determine validation mode for [" + resource + "]: 
cannot 
open InputStream. " + 
"Did you attempt to load directly from a SAX InputSource 
without 
specifying the " + 
"validationMode on your XmlBeanDefinitionReader instance?", 
ex); 
i 
try { 
return 
this.validationModeDetector.detect ValidationMode(inputStream); 
} 


catch (IOException ex) 1 
throw new BeanDefinitionStoreException(" Unable to determine 
validation mode for [" + 
resource + "]: an error occurred whilst reading from the 


InputStream.", ex); 


j 
XmlValidationModeDetector.java 
public int detectValidationMode(InputStream inputStream) throws 
IOException 1 
BufferedReader reader = new BufferedReader(new 
InputStreamReader(inputStream)); 
try { 
boolean isDtdValidated = false; 
String content; 
while ((content = reader.readLine()) != null) 1 
content - consumeCommentTokens(content); 
/如 果 读 取 的 行 是 空 或 者 是 注释 则 略 过 
if (this.inComment || !StringUtils.hasText(content)) 1 
continue; 
j 
if (hasDoctype(content)) 1 
isDtdValidated = true; 
break; 
j 
/ 读 取 到 < 开始 符号 ， 验 证 模式 一 定 会 在 开始 符号 之 前 
if (hasOpeningTag(content)) 1 


break; 


return (isDtdValidated ? VALIDATION DTD : 
VALIDATION XSD); 
i 
catch (CharConversionException ex) { 
/ Choked on some character encoding... 
// Leave the decision up to the caller. 
return VALIDATION AUTO; 
j 
finally { 


reader.close(); 


} 


private boolean hasDoctype(String content) | 
return (content.indexOf( DOCTY PE) > -1); 


j 

只 要 我 们 理解 了 XSD 与 DTD 的 使 用 方法 ， 理 解 上 面 的 代码 应 该 不 
会 太 难 ，Spring 用 来 检测 验证 模式 的 办 法 就 是 判断 是 否 包含 
DOCTYPE， 如 果 包 含 就 是 DTD， 否 则 就 是 XSD。 


2.7 ocument 


经 过 了 验证 模式 准备 的 步骤 就 可 以 进行 Document 加 载 了 ， 同 样 
XmlBeanFactoryReader 类 对 于 文档 读 取 并 没有 杀 力 杀 为 ， 而 是 委托 给 


了 DocumentLoader 去 执行 ， 这 里 的 DocumentLoader 是 个 接口 ， 而 真正 
调用 的 是 DefaultDocumentLoader， 解 析 代 码 如 下 : 

DefaultDocumentLoader.java 

public Document loadDocument(InputSource inputSource, 
EntityResolver entityResolver, 

Exception 1 

ErrorHandler errorHandler, int validationMode, boolean 
namespaceAware) throws 

DocumentBuilderFactory factory = 
createDocumentBuilderFactory(validationMode, 

namespaceAware) 

if (logger.isDebugEnabled()) { 

logger.debug(" Using JAXP provider [" + 

factory.getClass().getName() + "]"); 

} 

DocumentBuilder builder = createDocumentBuilder(factory, 
entityResolver, 

errorHandler); 

return builder.parse(inputSource); 

} 

对 于 这 部 分 代码 其 实 并 没有 太 多 可 以 描述 的 ， 因 为 通过 SAX 解 析 
XML 文档 的 套路 大 致 都 差不多 ，Spring 在 这 里 并 没有 什么 特殊 的 地 
方 ， 同 样 首先 创建 DocumentBuilderFactory， 再 通过 
DocumentBuilderFactory 创 建 DocumentBuilder， 进 而 解析 inputSource 来 
返回 Document 对 象 。 对 此 感 兴趣 的 读者 可 以 在 网 上 获取 更 多 的 资料 。 
这 里 有 必要 提 及 一 下 EntityResolver， 对 于 参数 entityResolver， 传 入 的 
是 通过 getEntityResolver0 汶 数 获取 的 返回 值 ， 如 下 代码 : 


protected EntityResolver getEntityResolver() 1 
if (this.entityResolver == null) 1 
// Determine default EntityResolver to use. 
ResourceLoader resourceLoader = getResourceLoader(); 
if (resourceLoader != null) { 
this.entityResolver = new 
ResourceEntityResolver(resourceLoader); 
} 
else { 
this.entityResolver = new DelegatingEntityResolver 
(getBeanClassLoader()); 
} 
} 
return this.entityResolver; 


} 
那么 ，EntityResolver 到 底 是 做 什么 用 的 呢 ? 


2.7.1 EntityResolver 用 法 


在 loadDocument 方 法 中 涉及 一 个 参数 EntityResolver， 何 为 


EntityResolver? 官网 这 样 解释 :如 果 SAX 应 用 程序 需要 实现 自 定 义 处 理 
外 部 实体 ， 则 必须 实现 此 接口 并 使 用 setEntityResolver 方 法 向 SAX 驱动 
器 注册 一 个 实例 。 也 就 是 说 ， 对 于 解析 一 个 XML ，SAX 首 先 读 取 该 

XML 文档 上 的 声明 ， 根 据 声 明 去 寻找 相应 的 DID 定义 ， 以 便 对 文档 进 
行 一 个 验证 。 默 认 的 寻找 规则 ， 即 通过 网 络 (实现 上 就 是 声明 的 DTD 
的 URI 地 址 ) 来 下 载 相应 的 DID 声明， 并 进行 认证 。 下 载 的 过 程 是 一 
个 漫长 的 过 程 ， 而 且 当 网 络 中 断 或 不 可 用 时 ， 这 里 会 报错 ， 就 是 因为 


相应 的 DID 声明 没有 被 找到 的 原因 。 


EntityResolver 的 作用 是 项 目 本 身 就 可 以 提供 一 个 如 何 寻 找 DTD 声 
明 的 方法 ， 即 由 程序 来 实现 寻找 DTD 声 明 的 过 程 ， 比 如 我 们 将 DTD 文 
件 放 到 项 目 中 某 处 ， 在 实现 时 直接 将 此 文档 读 取 并 返回 给 SAX 即 可 。 
这 样 就 避免 了 通过 网 络 来 寻找 相应 的 声明 。 

首先 看 entityResolver 的 接口 方法 声明 : 

InputSource resolveEntity(String publicId, String SystemId) 

这 里 ， 它 接收 两 个 参数 publicId 和 systemId， 并 返回 一 个 
inputSource 对 象 。 这 里 我 们 以 特定 配置 文件 来 进行 讲解 。 

(1) 如 果 我 们 在 解析 验证 模式 为 XSD 的 配置 文件 ， 代 码 如 下 : 

<?xml version="1.0" encoding="UTF-8"?> 

«beans xmlns-"http://www.Springframework.org/schema/beans" 


xmins:xsi-"http://www.w3.0rg/2001/XMLSchema-instance" 


xsi:schemaLocation="http://www.Springframework.org/schema/beans 
http://www. Springframework.org/schema/beans/Spring- 

beans.xsd"> 

</beans> 

读 取 到 以 下 两 个 参数 。 

publicId: null 

systemId: http://www.Springframework.org/schema/beans/Spring- 
beans.xsd 

(2) 如 果 我 们 在 解析 验证 模式 为 DID 的 配置 文件 ， 代 码 如 下 : 

<?xml version="1.0" encoding="UTF-8"?> 

<!DOCTYPE beans PUBLIC "-//Spring//DTD BEAN 2.0//EN" 
"http://www. Springframework. 

org/dtd/Spring-beans-2.0.dtd"> 


«beans? 
</beans> 
读 取 到 以 下 两 个 参数 。 
publicId: -//Spring//DTD BEAN 2.0//EN 
systemId: http://www.Springframework.org/dtd/Spring-beans-2.0.dtd 
之 前 已 经 提 到 过 ， 验 证 文件 默认 的 加 载 方式 是 通过 URL 进行 网 络 
下 载 获 取 ， 这 样 会 造成 延迟 ， 用 户 体验 也 不 好 ， 一 般 的 做 法 都 是 将 验 
证 文件 放置 在 自己 的 工程 里 ， 那 么 怎么 做 才能 将 这 个 URL 转 换 为 自己 
工程 里 对 应 的 地 址 文件 呢 ? 我 们 以 加 载 DTD 文 件 为 例 来 看 看 Spring 中 
是 如 何 实现 的 。 根 据 之 前 Spring 中 通过 getEntityResolver() 方 法 对 
EntityResolver 的 获取 ， 我 们 知道 ，Spring 中 使 用 
DelegatingEntityResolver 类 为 EntityResolver 的 实现 类 ，resolveEntity 实 
现 方 法 如 下 : 
DelegatingEntityResolver.java 
public InputSource resolveEntity(String publicId, String systemld) 
throws 
SAXException, IOException 1 
if (systemId != null) { 
if (systemId.endsWith(DTD SUFFIX)) { 
/如 果 是 dtd 从 这 里 解析 
return this.dtdResolver.resolveEntity(publicId, systemId); 
1 
else if (systemId.endsWith(XSD SUFFIX)) ( 
/通过 调用 META-INF/Spring.schemas 解 析 


return this.schemaResolver.resolveEntity(publicId, systemId); 


j 
return null; 
j 
我 们 可 以 看 到 ， 对 不 同 的 验证 模式 ，Spring 使 用 了 不 同 的 解析 器 
解析 。 这 里 简单 描述 一 下 原理 ， 比 如 加 载 DTD 类 型 的 
BeansDtdResolver 的 resolveEntity 是 直接 截取 systemId 最 后 的 xx.dtd 然 后 
去 当前 路 径 下 寻找 ， 而 加 载 XSD 类 型 的 PluggableSchemaResolver 类 的 
resolveEntity 是 默认 到 META-INF/Spring.schemas 文 件 中 找到 systemid 所 
对 应 的 XSD 文件 并 加 载 。 
BeansDtdResolver.java 
public InputSource resolveEntity(String publicId, String SystemId) 
throws IOException 1 
if (logger.isTraceEnabled()) 1 
logger.trace(" Trying to resolve XML entity with public ID [" + 
publicId + 
"] and system ID [" + systemId + "]"); 
j 
// DTD EXTENSION = ".dtd"; 
if (systemId != null && systemId.endsWith(DTD EXTENSION)) 


int lastPathSeparator = systemlId.lastIndexOf("/"); 
for (String DID NAME : DID NAMES) { 
// DID NAMES = {"Spring-beans-2.0", "Spring-beans" }; 
int dtdNameStart = systemId.indexOf(DTD NAME); 
if (dtdNameStart > lastPathSeparator) { 
String dtdFile = systemId.substring(dtdNameStart); 
if (logger.isTraceEnabled()) { 


logger.trace("Trying to locate [" + dtdFile + "] in Spring 
jar"); 
j 
try 1 
Resource resource = new ClassPathResource(dtdFile, 
getClass()); 
InputSource source - new 
InputSource(resource.getInputStream()); 
source.setPublicId(publicId); 
source.setSystemId(systemId); 
if (logger.isDebugEnabled()) 1 
logger.debug(" Found beans DTD [" + systemlId + "] in 
classpath: " + dtdFile); 
j 
return source; 
j 
catch (IOException ex) 1 
if (logger.isDebugEnabled()) { 
logger.debug(" Could not resolve beans DID [" + 
systemId 


+ "]: not found in class path", ex); 


} 


return null; 


2.8 > BeanDefinitions 


当 把 文件 转换 为 Document 后 ， 接 下 来 的 提取 及 注册 bean 就 是 我 们 
的 重头 戏 。 继 续 上 面 的 分 析 ， 当 程序 已 经 拥有 XML 文档 文件 的 
Document 实 例 对 象 时 ， 就 会 被 引入 下 面 这 个 方法 。 
XmlBeanDefinitionReader.java 
public int registerBeanDefinitions(Document doc, Resource resource) 
throws BeanDefinitionStore 
Exception 1 
//fs$ FHDefaultBeanDefinitionDocumentReaderSz fl {¥, 
BeanDefinitionDocumentReader 
BeanDefinitionDocumentReader documentReader = 
createBeanDefinitionDocumentReader(); 
/将 环境 变量 设置 其 中 
documentReader.setEnvironment(this.getEnvironment()); 
/在 实例 化 BeanDefinitionReader 时 候 会 将 
BeanDefinitionRegistry 传 入 ， 默 认 使 用 继承 上 自 
DefaultListableBeanFactory 的 子 类 
/记录 统计 前 BeanDefinition 的 加 载 个 数 
int countBefore = getRegistry().getBeanDefinitionCount(); 
// 加 载 及 注册 bean 
documentReader.registerBeanDefinitions(doc, 
createReaderContext(resource)); 
/记录 本 次 加 载 的 BeanDefinition 个 数 


return getRegistry().getBeanDefinitionCount() - countBefore; 


j 
其 中 的 参数 doc 是 通过 上 一 节 loadDocument 加 载 转换 出 来 的 。 在 
这 个 方法 中 很 好 地 应 用 了 面向 对 象 中 单一 职责 的 原则 ， 将 逻辑 处 理 委 
托 给 单一 的 类 进行 处 理 ， 而 这 个 逻辑 处 理 类 就 是 
BeanDefinitionDocumentReader。 BeanDefinitionDocumentReader 是 一 
个 接口 ， 而 实例 化 的 工作 是 在 createBeanDefinitionDocumentReader() 中 
完成 的 ， 而 通过 此 方法 ，BeanDefinitionDocumentReader 真 正 的 类 型 其 
实 已 经 是 DefaultBeanDefinitionDocumentReader 了 ， 进 入 
DefaultBeanDefinition Document Reader 后 ， 发 现 这 个 方法 的 重要 目的 
之 一 就 是 提取 root， 以 便于 再 次 将 root 作为 参数 继续 BeanDefinition 的 
注册 。 
public void registerBeanDefinitions(Document doc， 
XmlReaderContext readerContext) 1 
this.readerContext = readerContext; 
logger.debug(" Loading bean definitions"); 
Element root = doc.getDocumentElement(); 
doRegisterBeanDefinitions(root); 
j 
REEE, MAAF, ， 我 们 终于 到 了 核心 逻辑 的 底部 
doRegisterBeanDefinitions(root)， 至 少 我 们 在 这 个 方法 中 看 到 了 希望 。 
如 果 说 以 前 一 直 是 XML 加 载 解析 的 准备 阶段 ， 那 么 
doRegisterBeanDefinitions 算 是 真正 地 开始 进行 解析 了 ， 我 们 期 待 的 核 
心 部 分 真正 开始 了 。 
protected void doRegisterBeanDefinitions(Element root) { 
// 处 理 profile 属 性 
String profileSpec = root.getAttribute(PROFILE_ATTRIBUTE); 
if (StringUtils.hasText(profileSpec)) { 


Assert.state(this.environment != null, "environment property 
must not be null"); 

String[] specifiedProfiles = 
StringUtils.tokenizeToStringArray(profileSpec, 


BeanDefinitionParserDelegate. MULTI VALUE ATTRIBUTE DELIMITE 
RS); 
if (!this.environment.acceptsProfiles(specifiedProfiles)) 1 


return; 


i 
/专门 处 理解 析 
BeanDefinitionParserDelegate parent = this.delegate; 
this.delegate = createHelper(readerContext, root, parent); 
// 解 析 前 处 理 ， 留 给 子 类 实现 
preProcessXml(root); 
parseBeanDefinitions(root, this.delegate); 
/解析 后 处 理 ， 留 给 子 类 实现 
postProcessXml(root); 
this.delegate — parent; 
j 
通过 上 面 的 代码 我 们 看 到 了 处 理 流 程 ， 首 先是 对 profile 的 处 理 ， 
然后 开始 进行 解析 ， 可 是 当 我 们 跟 进 preProcessXml(root) 或 者 
postProcessXml(root) 发 现代 码 是 空 的， 既然 是 空 的 写 着 还 有 什么 用 
E? 就 像 面 向 对 象 设 计 方 法 学 中 常 说 的 一 句 话 ， 一 个 类 要 么 是 面向 继 
承 的 设计 的 ， 要 么 就 用 final 修 饰 。 在 
DefaultBeanDefinitionDocumentReader 中 并 没有 用 final 修 饰 ， 所 以 它 是 


面向 继承 而 设计 的 。 这 两 个 方法 正 是 为 子 类 而 设计 的 ， 如 果 读 者 有 了 
解 过 设计 模式 ， 可 以 很 快速 地 反映 出 这 是 模版 方法 模式 ， 如 果 继 承 自 
DefaultBeanDefinitionDocumentReader 的 子 类 需要 在 Bean 解 析 前 后 做 一 
些 处 理 的话 ， 那 么 只 需要 重 写 这 两 个 方法 就 可 以 了 。 


2.8.1 profile 属 性 的 使 用 


我 们 注意 到 在 注册 Bean 的 最 开始 是 对 PROFILE_ATTRIBUTE 属 性 
的 解析 ， 可 能 对 于 我 们 来 说 ，profile 属 性 并 不 是 很 常用 。 让 我 们 先 了 
解 一 下 这 个 属性 。 
分 析 profile 前 我 们 先 了 解 下 profile 的 用 法 ， 官 方 示 例 代 码 片 段 如 
T 
«beans xmlns-"http://www.Springframework.org/schema/beans" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xmins:jdbc-" http://www. 
Springframework.org/schema/jdbc" 
xmins:jee-"http://www.Springframework.org/schema/jee" 


xsi:schemaLocation="..."> 


</beans> 
<beans profile="production"> 
</beans> 
</beans> 
集成 到 Web 环 境 中 时 ， 在 web.xml 中 加 入 以 下 代码 : 


<context-param> 


<param-name>Spring.profiles.active</param-name> 

<param-value>dev</param-value> 

</context-param> 

有 了 这 个 特性 我 们 就 可 以 同时 在 配置 文件 中 部 署 两 套 配置 来 适用 
于 生产 环境 和 开发 环境 ， 这 样 可 以 方便 的 进行 切换 开发 、 部 署 环境 ， 
最 常用 的 就 是 更 换 不 同 的 数据 库 。 

了 解 了 profile 的 使 用 再 来 分 析 代 码 会 清晰 得 多 ， 首 先 程序 会 获取 
beans 节点 是 否定 义 了 profile 属性 ， 如 果 定 义 了 则 会 需要 到 环境 变量 
去 寻找 ， 所 以 这 里 首先 断言 environment 不 可 能 为 空 ， 因 为 profile 是 
可 以 同时 指定 多 个 的 ， 需 要 程序 对 其 拆 分 ， 并 解析 每 个 profile 是 都 符 
合 环境 变量 中 所 定义 的 ， 不 定义 则 不 会 浪费 性 能 去 解析 。 


2.8.2 解析 并 注册 BeanDefinition 
处 理 了 profile 后 就 可 以 进行 XML 的 读 取 了 ， 跟 踪 代 码 进 入 


parseBeanDefinitions(root, this.delegate). 
protected void parseBeanDefinitions(Element root, 
BeanDefinitionParserDelegate delegate) { 
/对 beans 的 处 理 
if (delegate.isDefaultNamespace(root)) { 
NodeList nl = root.getChildNodes(); 
for (int i = 0; i < nl.getLength(); i++) { 
Node node = nl.item(i); 
if (node instanceof Element) { 
Element ele = (Element) node; 
if (delegate.isDefaultNamespace(ele)) { 
/对 bean 的 处 理 
parseDefaultElement(ele, delegate); 


j 
else { 
/对 bean 的 处 理 


delegate.parseCustomElement(ele); 


j 
else { 


delegate.parseCustomElement(root); 


} 

上 面 的 代码 看 起 来 逻辑 还 是 蛮 清 晰 的 ， 因 为 在 Spring 的 XML 配置 
里 面 有 两 大 类 Bean 声 明 ， 一 个 是 默认 的 ， 如 : 

<bean id="test" class="test.TestBean"/> 

另 一 类 就 是 自 定义 的 ， 如 : 

<tx:annotation-driven/> 

而 两 种 方式 的 读 取 及 解析 差别 是 非常 大 的 ， 如 果 采 用 Spring 默认 
的 配置 ，Spring 当 然 知 道 该 怎么 做 ， 但 是 如 果 是 自 定义 的 ， 那 么 就 需 
要 用 户 实现 一 些 接口 及 配置 了 。 对 于 根 节点 或 者 子 节点 如 果 是 默认 命 
名 空间 的 话 则 采用 parseDefaultElement 方法 进行 解析 ， 否 则 使 用 
une pu 法 对 自 定义 命名 空间 进行 解析 。 而 判断 

否 上 默认 命名 空间 还 是 自 定义 命名 空间 的 办 法 其 实 是 使 用 
node.getrNamespaceURI() 获 取 命 名 空间 ， 并 与 Spring 中 国定 的 命名 空 
http://www.Springframework.org/schema/beans 进行 比 对 。 x 
为 是 默认 ， 否 则 就 认为 是 自 定义 。 而 对 于 默认 标签 解析 与 自 定义 标签 
解析 我 们 将 会 在 下 一 章 中 进行 讨论 。 


之 前 提 到 过 Spring 中 的 标签 包括 默认 标签 和 目 定 义 标签 两 种 ， 而 
两 种 标签 的 用 法 以 及 解析 方式 存在 着 很 大 的 不 同 ， 本 章节 重点 带领 读 
者 详细 分 析 默 认 标签 的 解析 过 程 。 

ead 是 在 parseDefaultElement 芍 数 中 进行 的 ， 卫 数 中 的 
功能 逻辑 一 目 了 然 ， 分 别 对 4 种 不 同 标签 〈import、alias、bean 和 
beans) 做 了 不 同 的 处 理 。 

private void parseDefaultElement(Element ele, 
BeanDefinitionParserDelegate delegate) 1 

/对 import 标 签 的 处 理 
if (delegate.nodeNameEquals(ele, IMPORT ELEMENT)) { 
importBeanDefinitionResource(ele); 
j 
// 对 alias 标 签 的 处 理 
else if (delegate.nodeNameEquals(ele, ALIAS ELEMENT)) 1 
processAliasRegistration(ele); 
j 
// 对 bean 标 签 的 处 理 
else if (delegate.nodeNameEquals(ele, BEAN ELEMENT)) { 
processBeanDefinition(ele, delegate); 
j 
/对 beans 标 等 的 处 理 
else if (delegate.nodeNameEquals(ele, 
NESTED BEANS ELEMENT)) 1 


doRegisterBeanDefinitions(ele); 


3.1 bean 标 签 的 解析 及 注册 


在 4 种 标签 的 解析 中 ， 对 bean 标签 的 解析 最 为 复杂 也 最 为 重要 ， 
所 以 我 们 从 此 标签 开始 深入 分 析 ， 如 果 能 理解 此 标签 的 解析 过 程 ， 其 
他 标签 的 解析 自然 会 迎刃而解 。 首 先 我 们 进入 函数 
processBeanDefinition(ele, delegate). 
protected void processBeanDefinition(Element ele, 
BeanDefinitionParserDelegate delegate) 1 
BeanDefinitionHolder bdHolder = 
delegate.parseBeanDefinitionElement(ele); 
if (bdHolder != null) { 
bdHolder - delegate.decorateBeanDefinitionIfRequired(ele, 
bdHolder); 
try { 
getRegistry()); 
BeanDefinitionReaderUtils.registerBeanDefinition(bdHolder, 
getReaderContext().&nbsp; | 
catch (BeanDefinitionStoreException ex) ( 
getReaderContext().error(" Failed to register bean definition 
with name ™ + 
bdHolder.getBeanName() + """, ele, ex); 
j 
getReaderContext().fireComponentRegistered(new 
BeanComponentDefinition(bdHolder)); 
} 


} 
乍 一 看 ， 似 乎 一 头 雾 水 ， 没 有 以 前 的 函数 那样 清晰 的 逻辑 。 大 致 
的 逻辑 总 结 如 下 。 

(1) 首先 委托 BeanDefinitionDelegate 类 的 
parseBeanDefinitionElement 方 法 进行 元 素 解析 ， 返 回 
BeanDefinitionHolder 类 型 的 实例 bdHolder， 经 过 这 个 方法 后 ，bdHolder 
实例 已 经 包含 我 们 配置 文件 中 配置 的 各 种 属性 了 ， 例 如 class、name、 
id、alias 之 类 的 属性 。 

(2) 当 返 回 的 bdHolder 不 为 空 的 情况 下 若 存 在 默认 标签 的 子 节 
点 下 再 有 自 定义 属性 ， 还 需要 再 次 对 自 定义 标签 进行 解析 。 

(3) 解析 完成 后 ， 需 要 对 解析 后 的 bdHolder 进行 注册 ， 同 样 ， 
注册 操作 委托 给 了 Bean DefinitionReaderUtils 的 registerBeanDefinition 
Aiko 

(4) 最 后 发 出 响应 事件 ， 通 知 想 关 的 监听 器 ， 这 个 bean 已 经 加 载 
完成 了 。 

配合 时 序 图 (如 图 3-1 所 示 ) ， 可 能 会 更 容易 理解 。 


图 3-1 bean 标 签 的 解析 及 注册 时 序 图 


3.1.1 BeanDefinition 


FAT TUE OG 8T RIFLES Aro ELEC TA TRENT fS 
息 提 取 开 始 ， 也 就 是 BeanDefinitionHolder bdHolder = 
delegate.parseBeanDefinitionElement(ele)， 进 入 BeanDefinition Delegate 
类 的 parseBeanDefinitionElement 方 法 。 

BeanDefinitionDelegate.java 

public BeanDefinitionHolder parseBeanDefinitionElement(Element 
ele) { 

return parseBeanDefinitionElement(ele, null); 

j 

public BeanDefinitionHolder parseBeanDefinitionElement(Element 
ele, BeanDefinition 


containingBean) 1 


/解析 id 属 性 
String id = ele.getAttribute(ID ATTRIBUTE); 
/解析 name 属 性 
String nameAttr = ele.getAttribute(NAME ATTRIBUTE); 
/分 割 name 属 性 


List<String> aliases = new ArrayList<String>(); 
if (StringUtils.hasLength(nameAttr)) { 
String[] nameArr = 
StringUtils.tokenizeToStringArray(nameAttr, MULTI 
VALUE ATTRIBUTE DELIMITERS); 
aliases.addAll(Arrays.asList(nameArr)); 


String beanName = id; 
if (IStringUtils.hasText(beanName) && !aliases.isEmpty()) { 
beanName = aliases.remove(0); 
if (logger.isDebugEnabled()) { 
logger.debug("No XML 'id' specified - using " + beanName 


"' as bean name and " + aliases + " as aliases"); 


j 
if (containingBean == null) { 
checkNameUniqueness(beanName, aliases, ele); 
} 
AbstractBeanDefinition beanDefinition = 
parseBeanDefinitionElement(ele, beanName, 
containingBean); 
if (beanDefinition != null) { 
if (!StringUtils.hasText(beanName)) { 
try { 
/如 果 不 存在 beanName 那 么 根据 Spring 中 提供 的 命名 规 
则 为 当前 bean 生 成 对 应 
的 beanName 
if (containingBean != null) { 
beanName = 
BeanDefinitionReaderUtils.generateBeanName( 
beanDefinition, this.readerContext.getRegistry(), true); 
j 


else { 


beanName = 
this.readerContext.generateBeanName(beanDefinition); 
String beanClassName = 
beanDefinition.getBeanClassName(); 
if (beanClassName != null && 
> beanClassName.length() && 
beanName.startsWith(beanClassName) && 
beanName.length() 
(beanClassName)) 1 
Ithis.readerContext.getRegistry(). ISBeanNameInUse 


aliases.add(beanClassName); 


j 
if (logger.isDebugEnabled()) { 
logger.debug(" Neither XML 'id' nor 'name' specified - " + 


"using generated bean name [" + beanName + "]"); 


} 
catch (Exception ex) { 
error(ex.getMessage(), ele); 


return null; 


} 
String[] aliasesArray = StringUtils.toStringArray(aliases); 
return new BeanDefinitionHolder(beanDefinition, beanName, 


aliasesArray); 


} 


return null; 
j 
以 上 便 是 对 默认 标签 解析 的 全 过 程 了 。 当 然 ， 对 Spring 的 解析 犹 
如 洋 和 外 剥皮 一 样 ， 一 层 一 层 地 进行 ， 尽 管 现在 只 能 看 到 对 属性 id 以 及 
name 的 解析 ， 但 是 很 庆 斑 ， 思 路 我 们 已 经 了 解 了 。 在 开始 对 属性 展开 
全 面 解析 前 ，Spring 在 外 层 又 做 了 一 个 当前 层 的 功能 架构 ， 在 当前 层 
完成 的 主要 工作 包括 如 下 内 容 。 
(1) 提取 元 素 中 的 id 以 及 name 属 性 。 
(2) 进一步 解析 其 他 所 有 属性 并 统一 封装 至 
GenericBeanDefinition 类 型 的 实例 中 。 
(3) 如 果 检 测 到 bean 没 有 指定 beanName， 那 么 使 用 默认 规则 为 
此 Bean 生 成 beanName。 
(4) 将 获取 到 的 信息 封装 到 BeanDefinitionHolder 的 实例 中 。 
我 们 进一步 地 查看 步骤 (2) 中 对 标签 其 他 属性 的 解析 过 程 。 
public AbstractBeanDefinition parseBeanDefinitionElement( 
Element ele, String beanName, BeanDefinition containingBean) 1 
this.parseState.push(new BeanEntry(beanName)); 
String className - null; 
/解析 class 属 性 
if (ele.hasAttribut((CLASS ATTRIBUTE)) 1 
className = ele.getAttribute(CLASS ATTRIBUTE).trim(); 
j 
try { 
String parent = null; 
/解析 parent 属 性 
if (ele.hasAttribute(PARENT_ATTRIBUTE)) { 
parent = ele.getAttribute(PARENT ATTRIBUTE); 


j 

/创建 用 于 承载 属性 的 AbstractBeanDefinition 类 型 的 
GenericBeanDefinition 

AbstractBeanDefinition bd = createBeanDefinition(className, 
parent); 

// 硬 编码 解析 默认 bean 的 各 种 属性 

parseBeanDefinitionAttributes(ele, beanName, containingBean, 
bd); 

// 提 取 description 

ELEMENT)); 


bd.setDescription(DomUtils.getChildElementValueByTagName(ele, 
DESCRIPTION . 
/解析 元 数据 
parseMetaElements(ele, bd); 
// 解 析 lookup-method 属 性 
parseLookupOverrideSubElements(ele, 
bd.getMethodOverrides()); 
// 解 析 replaced-method 属 性 
parseReplacedMethodSubElements(ele, 
bd.getMethodOverrides()); 
IRRITEER SLES BN 
parseConstructorArgElements(ele, bd); 
/解析 property 子 元 素 
parsePropertyElements(ele, bd); 
/解析 qualifier 子 元 素 


parseQualifierElements(ele, bd); 


bd.setResource(this.readerContext.getResource()); 
bd.setSource(extractSource(ele)); 
return bd; 
j 
catch (ClassNotFoundException ex) 1 
error(" Bean class [" + className + "] not found", ele, ex); 
j 
catch (NoClassDefFoundError err) { 
error("Class that bean class [" + className + "] depends on not 
found", ele, err); 
i 
catch (Throwable ex) { 
error("Unexpected failure during bean definition parsing", ele, 
ex); 
l 
finally { 
this.parseState.pop(); 
j 
return null; 
j 
终于 ，bean 标 签 的 所 有 属性 ， 不 论 常用 的 还 是 不 常用 的 我 们 都 看 
到 了 ， 尽 管 有 些 复杂 的 属性 还 需要 进一步 的 解析 ， 不 过 丝毫 不 会 影响 
我 们 兴奋 的 心情 。 接 下 来 ， 我 们 继续 一 些 复杂 标签 属性 的 解析 。 
1. 创建 用 于 属性 承载 的 BeanDefinition 
BeanDefinition 是 一 个 接口 ， 在 Spring 中 存在 三 种 实现 : 
RootBeanDefinition、 ChildBean Definition 以 及 
GenericBeanDefinition。 三 种 实现 均 继 承 了 AbstractBeanDefiniton ， 其 


FHBeanDefinition 是 配置 文件 <bean> 元 素 标签 在 容器 中 的 内 部 表示 形 
式 。 <bean> 元 素 标 签 拥有 class、scope、lazy-init 等 配置 属性 ， 
BeanDefinition 则 提供 了 相应 的 beanClass、scope、lazyInit 属 性 ， 
BeanDefinition 和 <bean> 中 的 属性 是 一 一 对 应 的 。 其 中 
RootBeanDefinition 是 最 常用 的 实现 类 ， 它 对 应 一 般 性 的 <bean> 元 素 标 
签 ，GenericBeanDefinition 是 自 2.5 版 本 以 后 新 加 入 的 bean 文 件 配置 属性 
定义 类 ， 是 一 站 式 服 务 类 。 

在 配置 文件 中 可 以 定义 父 <bean> 和 子 <bean>， 父 <bean> 用 
RootBeanDefinition 表 示 ， 而 子 <bean> 用 ChildBeanDefiniton 表 示 ， 而 疫 
有 父 <bean> 的 <bean> 就 使 用 RootBeanDefinition 表 示 。 
AbstractBeanDefinition 对 两 者 共同 的 类 信息 进行 抽象 。 

Spring 通过 BeanDefinition 将 配置 文件 中 的 <bean> 配 置信 息 转换 为 
容器 的 内 部 表示 ， 并 将 这 些 BeanDefiniton 注 册 到 BeanDefinitonRegistry 
中 。Spring 容 器 的 BeanDefinitionRegistry 就 像 是 Spring 配置 信息 的 内 存 
数据 库 ， 主 要 是 以 map 的 形式 保存 ， 后 续 操 作 直 接 从 BeanDefinition 
Registry 中 读 取 配置 信息 。 它 们 之 间 的 关系 如 图 3-2 所 示 。 
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图 3-2 BeanDefinition 及 其 实现 类 


由 此 可 知 ， 要 解析 属性 首先 要 创建 用 于 承载 属性 的 实例 ， 也 就 是 
创建 GenericBeanDefinition 类 型 的 实例 。 而 代码 
createBeanDefinition(className, parent) 的 作用 就 是 实现 此 功能 。 

protected AbstractBeanDefinition createBeanDefinition(String 
className, String parentName) 

throws ClassNotFoundException 1 

return BeanDefinitionReaderUtils.createBeanDefinition( 
parentName, className, 
this.readerContext.getBeanClassLoader()); 

} 

BeanDefinitionReaderUtils.java 


public static AbstractBeanDefinition createBeanDefinition( 


String parentName, String className, ClassLoader classLoader) 
throws 
ClassNotFoundException 1 
GenericBeanDefinition bd = new GenericBeanDefinition(); 
/parentName 可 能 为 空 
bd.setParentName(parentName); 
if (className !- null) { 
if (classLoader != null) { 
/如 果 classLoader 不 为 空 ， 则 使 用 以 传 入 的 classLoader 同 一 虚 
拟 机 加 载 类 对 象 ， 否 则 只 是 
记录 className 
bd.setBeanClass(ClassUtils.forName(className, 
classLoader)); 
j 
else { 


bd.setBeanClassName(className); 


j 
return bd; 
j 
2. 解析 各 种 属性 
当 我 们 创建 了 bean 信 息 的 承载 实例 后 ， 便 可 以 进行 bean 信 息 的 各 
种 属性 解析 了 ， 首 先 我 们 进入 parseBeanDefinitionAttributes 方 法 。 
parseBeanDefinitionAttributes 方 法 是 对 element 所 有 元 素 属性 进行 解析 : 
public AbstractBeanDefinition parseBeanDefinitionAttributes( Element 
ele, String beanName, 


BeanDefinition containingBean, AbstractBeanDefinition bd) 1 


/解析 scope 属 性 
if (ele.hasAttribut((SCOPE ATTRIBUTE)) 1 
// Spring 2.x "scope" attribute 
bd.setScope(ele.getAttribute(SCOPE_ATTRIBUTE)); 
if (ele.hasAttribute(SINGLETON ATTRIBUTE)) { 
/scope 与 singleton 两 个 属性 只 能 指定 其 中 之 一 ， 不 可 以 同时 出 
现 ， 否 则 Spring 将 会 报 出 异常 
error(" Specify either 'scope' or 'singleton', not both", ele); 
j 
j 
/解析 singleton 属 性 
else if (ele.hasAttribute(SINGLETON_ATTRIBUTE)) 1 
// Spring 1.x "singleton" attribute 


bd.setScope(TRUE VALUE.equals(ele.getAttribute(SINGLETON ATTRI 
BUTE)) ? 
BeanDefinition.SCOPE SINGLETON : 

BeanDefinition.SCOPE PROTOTYPE); 

i 

else if (containingBean != null) { 

// Take default from containing bean in case of an inner bean 
definition. 

J/ITEËR NbeanDifinition' 
父 类 默认 的 属性 

bd.setScope(containingBean.getScope()); 
} 
/解析 abstract 属 性 


青 况 下 且 没 有 单独 指定 scope 属 性 则 使 用 


if (ele.hasAttribute(ABSTRACT ATTRIBUTE)) { 


bd.setAbstract( TRUE  VALUE.equals(ele.getAttribute(ABSTRACT ATTR 
IBUTE))); 
j 
/解析 lazy-init 属 性 
String lazyInit = ele.getAttribute(LAZY INIT ATTRIBUTE); 
if (DEFAULT VALUE.equals(lazylInit)) 1 
lazyInit = this.defaults.getLazyInit(); 
j 
// 若 没有 设置 或 设置 成 其 他 字符 都 会 被 设置 为 false 
bd.setLazyInit(TRUE_VALUE.equals(lazyInit)); 
/解析 autowire 属 性 
String autowire = ele.getAttribute( AUTOWIRE ATTRIBUTE); 
bd.setAutowireMode(getAutowireMode(autowire)); 
/解析 dependency-check 属 性 
String dependencyCheck = 
ele.getAttribute(DEPENDENCY CHECK, ATTRIBUTE); 
bd.setDependencyCheck(getDependencyCheck(dependencyCheck)); 
// 解 析 depends-on 属 性 
if (ele.hasAttribut(DEPENDS ON ATTRIBUTE)) { 
String dependsOn = 
ele.getAttribute(DEPENDS ON. ATTRIBUTE); 
bd.setDependsOn(StringUtils.tokenizeToStringArray(dependsOn, 
MULTI VALUE 
ATTRIBUTE DELIMITERS)); 


/解析 autowire-candidate 属 性 
String autowireCandidate = 
ele.getAttribute(AUTOWIRE_CANDIDATE_ATTRIBUTE); 
if ("".equals(autowireCandidate) || 
DEFAULT_VALUE.equals(autowireCandidate)) { 
String candidatePattern = this.defaults.getAutowireCandidates(); 
if (candidatePattern != null) { 
String[] patterns = 
StringUtils.commaDelimitedListToStringArray 


(candidatePattern); 


bd.setAutowireCandidate(PatternMatchUtils.simpleMatch(patterns, 
beanName)); 
} 
} 


else { 


bd.setAutowireCandidate(TRUE_VALUE.equals(autowireCandidate)); 
} 
// 解 析 primary 属 性 
if (ele.hasAttribut( PRIMARY ATTRIBUTE)) { 


bd.setPrimary(TRUE VALUE.equals(ele.getAttribute(PRIMARY ATTRIB 
UTE))); 

} 

/解析 init-method 属 性 

if (ele.hasAttribut(INIT METHOD ATTRIBUTE)) { 


String initMethodName = 
ele.getAttribute(INIT_METHOD_ATTRIBUTE); 
if (!"".equals(initMethodName)) { 
bd.setInitMethodName(initMethodName); 


} 
else { 
if (this.defaults.getInitMethod() != null) { 
bd.setInitMethodNamex(this.defaults.getInitMethod()); 
bd.setEnforceInitMethod(false); 


} 
/解析 destroy-method 属 性 
if (ele.hasAttribut(DESTROY METHOD ATTRIBUTE)) { 
String destroyMethodName = 
ele.getAttribute(DESTROY METHOD ATTRIBUTE); 
if (!"".equals(destroyMethodName)) { 
bd.setDestroyMethodName(destroyMethodName); 


} 
else { 
if (this.defaults.getDestroyMethod() != null) { 
bd.setDestroyMethodName(this.defaults. getDestroyMethod()); 
bd.setEnforceDestroyMethod(false); 


} 
/解析 factory-method 属 性 


if (ele.hasAttribut(FACTORY METHOD ATTRIBUTE)) { 


bd.setFactoryMethodName(ele.getAttribute(FACTORY METHOD ATTRI 
BUTE)); 

} 

/解析 factory-bean 属 性 

if (ele.hasAttribut(FACTORY BEAN ATTRIBUTE)) ( 


bd.setFactoryBeanName(ele.getAttribute(FACTORY BEAN ATTRIBUTE 
)); 
i 
return bd; 
j 
我 们 可 以 清楚 地 看 到 Spring 完成 了 对 所 有 bean 属 性 的 解析 ， 这 些 
属性 中 有 很 多 是 我 们 经 常 使 用 的 ， 同 时 我 相信 也 一 定 会 有 或 多 或 少 的 
属性 是 读者 不 熟悉 或 者 是 没有 使 用 过 的 ， 有 兴趣 的 读者 可 以 查阅 相关 
资料 进一步 了 解 每 个 属性 。 
3. 解析 子 元 素 meta 
在 开始 解析 元 数据 的 分 析 前 ， 我 们 先 回 顾 下 元 数据 meta 属 性 的 使 
用 。 
<bean id="myTestBean" class="bean.MyTestBean"> 
«meta key="testStr" value="aaaaaaaa"/> 
</bean> 
这 段 代码 并 不 会 体现 在 MyTestBean 的 属性 当中 ， 而 是 一 个 额外 
的 声明 ， 当 需要 使 用 里 面 的 信息 的 时 候 可 以 通过 BeanDefinition 的 
getAttribute(key) 方 法 进行 获取 。 
对 meta 属 性 的 解析 代码 如 下 : 


public void parseMetaElements(Element ele, 
BeanMetadataAttributeAccessor attributeA ccessor) 1 
/获取 当前 节点 的 所 有 子 元素 
NodeList nl = ele.getChildNodes(); 
for (int i = 0; i < nl.getLength(); i++) { 
Node node - nl.item(i); 
// 提 取 meta 
if (isCandidateElement(node) && nodeNameEquals(node, 
META, ELEMENT)) { 
Element metaElement = (Element) node; 
String key = metaElement.getAttribute(KEY ATTRIBUTE); 
String value = 
metaElement.getAttribute( VALUE ATTRIBUTE); 
/使 用 key、value 构 造 BeanMetadataAttribute 
BeanMetadataAttribute attribute = new 
BeanMetadataAttribute(key, value); 
attribute.setSource(extractSource(metaElement)); 
/记录 信息 
attributeAccessor.addMetadataAttribute(attribute); 


} 

4。 解 析 子 元 素 lookup-method 

同样 ， 子 元 素 lookup-method 似乎 并 不 是 很 常用 ， 但 是 在 某 些 时 
候 它 的 确 是 非常 有 用 的 属性 ， 通 常 我 们 称 它 为 获取 器 注入 。5 引 用 
《Spring in Action》 中 的 一 句 话 : 获取 器 注入 是 一 种 特殊 的 方法 注 
入 ， 它 是 把 一 个 方法 声明 为 返回 某 种 类 型 的 bean， 但 实际 要 返回 的 


bean 是 在 配置 文件 里 面 配置 的 ， 此 方法 可 用 在 设计 有 些 可 插 拔 的 功能 
上 ， 解 除 程序 依赖 。 我 们 看 看 具体 的 应 用 。 
(1) 首先 我 们 创建 一 个 父 类 。 
package test.lookup.bean; 
public class User { 
public void showMe()1 


System.out.println("i am user"); 


j 
(2) 6/38 F-25378 SshowMeA ko 
package test.lookup.bean; 
public class Teacher extends User{ 
public void showMe(){ 


System.out.printin("i am Teacher"); 


} 
(3) 创建 调用 方法 。 
public abstract class GetBeanTest { 
public void showMe()1 
this.getBean().showMe(); 
} 
public abstract User getBean(); 
} 
(4) 创建 测试 方法 。 
package test.lookup; 


import org.Springframework.context.A pplicationContext; 


import 
org.Springframework.context.support.ClassPathXmlA pplicationContext; 
import test.lookup.app.GetBeanTest; 
public class Main { 
public static void main(String[] args) { 
ApplicationContext bf = 
new 
ClassPathXmlApplicationContext("test/lookup/lookupTest.xml"); 
GetBeanTest test=(GetBeanTest) bf.getBean("getBeanTest"); 
test.showMe(); 


} 

到 现在 为 止 ， 除 了 配置 文件 外 ， 整 个 测试 方法 就 完成 了 ， 如 果 之 
1 没有 接触 过 获取 器 注入 的 读者 们 可 能 会 有 疑问 : 抽象 方法 还 没有 被 
现 ， 怎 么 可 以 直接 调用 呢 ? 答案 就 在 Spring 为 我 们 提供 的 获取 器 
中 ， 我 们 看 看 配置 文件 是 怎么 配置 的 。 

<?xml version="1.0" encoding="UTF-8"?> 
«beans xmlns-"http://www.Springframework.org/schema/beans" 


xmins:xsi-"http://www.w3.0rg/2001/XMLSchema-instance" 


xsi:schemaLocation-"http://www.Springframework.org/schema/beans 
http://www. Springframework. 
org/schema/beans/Spring-beans.xsd"> 
<bean id="getBeanTest" class="test.lookup.app.GetBeanTest"> 
<lookup-method name="getBean" bean="teacher"/> 
</bean> 


<bean id="teacher" class="test.lookup.bean. Teacher"/> 


</beans> 

在 配置 文件 中 ， 我 们 看 到 了 源码 解析 中 提 到 的 lookup-method 子 元 
素 ， 这 个 配置 完成 的 功能 是 动态 地 将 teacher 所 代表 的 bean 作 为 getBean 
的 返回 值 ， 运 行 测试 方法 我 们 会 看 到 控制 全 上 的 输出 : 

i am Teacher 

当 我 们 的 业务 变更 或 者 在 其 他 情况 下 ，teacher 里 面 的 业务 逻辑 已 
经 不 再 符合 我 们 的 业务 要 求 ， 需 要 进行 替换 怎么 办 呢 ? 这 是 我 们 需 
增加 新 的 逻辑 类 : 

package test.lookup.bean; 

public class Student extends User { 

public void showMe(){ 


System.out.println("i am student"); 


j 

同时 修改 配置 文件 : 

<?xml version="1.0" encoding="UTF-8"?> 

«beans xmlns-"http://www.Springframework.org/schema/beans" 


xmins:xsi-"http://www.w3.0rg/2001/XMLSchema-instance" 


xsi:schemaLocation="http://www.Springframework.org/schema/beans 
http://www. Springframework. 
org/schema/beans/Spring-beans.xsd"> 
<bean id-"getBeanTest" class="test.lookup.app.GetBeanTest"> 
<lookup-method name="getBean" bean="student"/> 
</bean> 
<bean id="teacher" class="test.lookup.bean. Teacher"/> 


<bean id="student" class="test.lookup.bean.Student"/> 


</beans> 
再 次 运行 测试 类 ， 你 会 发 现 不 一 样 的 结果 : 
i am Student 
至 此 ， 我 们 已 经 初步 了 解 了 lookup-method 子 元 素 所 提供 的 大 致 
功能 ， 相 信 这 时 再 次 去 看 它 的 属性 提取 源码 会 觉得 更 有 针对 性 。 
public void parseLookupOverrideSubElements(Element beanEle, 
MethodOverrides overrides) 1 
NodeList nl = beanEle.getChildNodes(); 
for (int i = 0; i < nl.getLength(); i++) { 
Node node = nl.item(i); 


/ 仅 当 在 Spring 默认 bean 的 子 元 素 下 且 为 <lookup-method 时 有 


METHOD ELEMENT)) { 
if (isCandidateElement(node) && nodeNameEquals(node, 
LOOKUP. 
Element ele = (Element) node; 
/获取 要 修饰 的 方法 
String methodName = ele.getAttribute(NAME ATTRIBUTE); 
/获取 配置 返回 的 bean 
String beanRef = ele.getAttribute(BEAN ELEMENT); 
LookupOverride override = new 
LookupOverride(methodName, beanRef); 
override.setSource(extractSource(ele)); 


overrides.addOverride(override); 


上 面 的 代码 很 眼熟 ， 似 乎 与 parseMetaElements 的 代码 大 同 小 异 ， 
最 大 的 区 别 就 是 在 if 判 断 中 的 节点 名 称 在 这 里 被 修改 为 
LOOKUP_METHOD_ELEMENT。 还 有 ， 在 数据 存储 上 面 通过 使 用 
LookupOverride 类 型 的 实体 类 来 进行 数据 承载 并 记录 在 
AbstractBeanDefinition 中 的 methodOverrides 属 性 中 。 
5。 解 析 子 元 素 replaced-method 
这 个 方法 主要 是 对 bean 中 replaced-method 子 元 素 的 提取 ， 在 开始 
提取 分 析 之 前 我 们 还 是 预先 介绍 下 这 个 元 素 的 用 法 。 
方法 替换 : 可 以 在 运行 时 用 新 的 方法 替换 现 有 的 方法 。 与 之 前 的 
look-up 不 同 的 是 ， replaced-method 不 但 可 以 动态 地 替换 返回 实体 
bean， 而 且 还 能 动态 地 更 改 原 有 方法 的 逻辑 。 我 们 来 看 看 使 用 示例 。 
(1) 在 changeMe 中 完成 某 个 业务 逻辑 。 
public class TestChangeMethod { 
public void changeMe()1 
System.out.printIn("changeMe"); 
j 
j 
(2) 在 运营 一 段 时 间 后 需要 改变 原 有 的 业务 逻辑 。 
public class TestMethodReplacer implements MethodReplacer{ 
@Override 
public Object reimplement(Object obj, Method method, Object 
args)throws Throwable { 
System.out.println(" 我 替换 了 原 有 的 方法 "); 


return null; 


} 
(3) 使 替换 后 的 类 生效 。 


<?xml version="1.0" encoding="UTF-8"?> 
«beans xmlns-"http://www.Springframework.org/schema/beans" 
xmins:xsi-"http://www.w3.0rg/2001/XMLSchema-instance" 
xsi:schemaLocation="http://www.Springframework.org/schema/beans 
http://www. Springframework. 
org/schema/beans/Spring-beans.xsd"> 
<bean id="testChangeMethod" 
class="test.replacemethod.TestChangeMethod"> 
«replaced-method name="changeMe" replacer="replacer"/> 
</bean> 
<bean id="replacer" 
class="test.replacemethod.TestMethodReplacer"/> 
</beans> 
(4) 测试 。 
public static void main(String[] args) 1 
ApplicationContext bf = 
new 
ClassPathXmlApplicationContext("test/replacemethod/replaceMethodTest. 
xml"); 
TestChangeMethod test=(TestChangeMethod) 
bf.getBean("testChangeMethod"); 
test.changeMe(); 
} 
好 了 ， 运 行 测 试 类 就 可 以 看 到 预期 的 结果 了 ， 控 制 台 成 功 打 印 出 
“我 替换 了 原 有 的 方法 ”， 也 就 是 说 我 们 做 到 了 动态 替换 原 有 方法 ， 知 
道 了 这 个 元 素 的 用 法 ， 我 们 再 次 来 看 元 素 的 提取 过 程 : 


public void parseReplacedMethodSubElements(Element beanEle, 
MethodOverrides overrides) 1 
NodeList nl = beanEle.getChildNodes(); 
for (int i = 0; i < nl.getLength(); i++) { 
Node node = nl.item(i); 


/ 仅 当 在 Spring 默认 bean 的 子 元 素 下 且 为 <replaced-method 时 有 


ELEMENT)) { 
if (isCandidateElement(node) && nodeNameEquals(node, 
REPLACED METHOD . 
Element replacedMethodEle = (Element) node; 
/提取 要 替换 的 旧 的 方法 
String name = 
replacedMethodEle.getAttribute(:NAME ATTRIBUTE); 
/提取 对 应 的 新 的 替换 方法 
String callback = 
replacedMethodEle.getAttribute(REPLACER, ATTRIBUTE); 
ReplaceOverride replaceOverride = new 
ReplaceOverride(name, callback); 
List<Element> argTypeEles = 
DomUtils.getChildElementsByTagName 
(replacedMethodEle, ARG TYPE ELEMENT); 
for (Element argTypeEle : argTypeEles) 1 
/记录 参数 
String match = argTypeEle.getAttribute 
(ARG. TYPE MATCH ATTRIBUTE); 


match = (StringUtils.hasText(match) ? match : 
DomUtils.getTextValue 
(argTypeEle)); 
if (StringUtils.hasText(match)) { 
replaceOverride.addTypeldentifier(match); 


} 
replaceOverride.setSource(extractSource(replacedMethodEle)); 


overrides.addOverride(replaceOverride); 


} 

我 们 可 以 看 到 无 论 是 look-up 还 是 replaced-method 都 是 构造 了 一 个 
MethodOverride， 并 最 终 记 录 在 了 AbstractBeanDefinition 中 的 
methodOverrides 属 性 中 。 而 这 个 属性 如 何 使 用 以 完成 它 所 提供 的 功能 
我 们 会 在 后 续 的 章节 进行 详细 地 介绍 。 

6. 解析 子 元 素 constructor-arg 

对 构造 遂 数 的 解析 是 非常 常用 的 ， 同 时 也 是 非常 复杂 的 ， 也 相信 
大 家 对 构造 函数 的 配置 都 不 陌生 ， 举 个 简单 的 小 例子 : 

«beans? 

<!-- 默认 的 情况 下 是 按照 参数 的 顺序 注入 ， 当 指定 index 索 引 后 就 
可 以 改变 注入 参数 的 顺序 --> 

<bean id="helloBean" class="com.HelloBean"> 

<constructor-arg index="0"> 
<value> 郝 佳 </value> 


</constructor-arg> 


«constructor-arg index="1"> 
<value> 你 好 </value> 
</constructor-arg> 
</bean> 
</beans> 
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就 是 对 HelloBean 自 动 寻找 对 应 的 构造 水 数 ， 并 在 初始 化 的 时 候 将 设置 
的 参数 传 入 进去 。 那 么 让 我 们 来 看 看 具体 的 XML 解析 过 程 。 
对 于 constructor-arg 子 元 素 的 解析 ，Spring 是 通过 
parseConstructorArgElements 孙 数 来 实现 的 ， 有 具体 的 代码 如 下 : 
public void parseConstructorArgElements(Element beanEle, 
BeanDefinition bd) 1 
NodeList nl = beanEle.getChildNodes(); 
for (int i = 0; i < nl.getLength(); i++) ( 
Node node - nl.item(i); 
if (isCandidateElement(node) && nodeNameEquals(node, 
CONSTRUCTOR  ARG ELEMENT)) { 
/解析 constructor-arg 
parseConstructorArgElement((Element) node, bd); 


} 

这 个 结构 似乎 我 们 可 以 想象 得 到 ， 人 遍历 所 有 子 元 素 ， 也 就 是 提取 
所 有 constructor-arg， 然 后 进行 解析 ， 但 是 具体 的 解析 却 被 放置 在 了 另 
个 了 国 数 parseConstructorArgElement 中 ， 有 具体 代码 如 下 : 


public void parseConstructorArgElement(Element ele, BeanDefinition 
bd) { 
/提取 index 属 性 
String indexAttr = ele.getAttribute((INDEX_ATTRIBUTE); 


/提取 type 属 性 
String typeAttr = ele.getAttribute(TYPE ATTRIBUTE); 


/提取 name 属 性 
String nameAttr = ele.getAttribute(NAME ATTRIBUTE); 
if (StringUtils.hasLength(indexAttr)) { 
try { 
int index = Integer.parseInt(indexA ttr); 
if (index < 0) { 
error("'index' cannot be lower than 0", ele); 
jelse { 
try 1 
this.parseState.push(new 


ConstructorArgumentEntry(index)); 
/解析 ele 对 应 的 属性 元 素 
Object value = parseProperty Value(ele, bd, null); 


ConstructorArgument Values. ValueHolder valueHolder = 
new 
ConstructorArgumentValues. ValueHolder(value); 
if (StringUtils.hasLength(typeAttr)) { 
valueHolder.set Type(typeA ttr); 
j 
if (StringUtils.hasLength(nameAttr)) { 


valueHolder.setName(nameA ttr); 


j 
valueHolder.setSource(extractSource(ele)); 
/不 允许 重复 指定 相同 参数 
if (bd.getConstructorArgumentValues(). 
hasIndexedArgumentValue 
(index)) 1 
error(" Ambiguous constructor-arg entries for index " + 
index, ele); 
jelse 1 
(index, valueHolder); 
bd.getConstructorArgumentValues(). 
AddIndexedArgument Value 
} 
}finally { 
this.parseState.pop(); 


} 
}catch (NumberFormatException ex) { 
error(" Attribute 'index' of tag 'constructor-arg' must be an 


integer", ele); 


j 

yelse 1 
/没有 index 属 性 则 忽略 去 属性 ， 自 动 寻找 
try { 


this.parseState.push(new ConstructorArgumentEntry()); 


Object value = parseProperty Value(ele, bd, null); 


ConstructorArgumentValues. ValueHolder valueHolder = new 
Constructor 

ArgumentValues. ValueHolder(value); 

if (StringUtils.hasLength(typeAttr)) { 
valueHolder.setType(typeAttr); 

} 

if (StringUtils.hasLength(nameAttr)) { 
valueHolder.setName(nameA ttr); 


} 


valueHolder.setSource(extractSource(ele)); 


bd.getConstructorArgumentValues().addGenericArgumentValue(valueHold 


er); 
} 
finally { 
this.parseState.pop(); 


} 
上 面 一 段 看 似 复杂 的 代码 让 很 多 人 失去 了 耐心 ， 但 是 ， 涉 及 的 逻 
辑 其 实 并 不 复杂 ， 首 先是 提取 constructor-arg 上 必要 的 属性 (index, 
type、name) 。 
如 果 配 置 中 指定 了 index 属 性 ， 那 么 操作 步骤 如 下 。 
(1) 解析 constructor-arg 的 子 元 素 。 
(2) 使 用 ConstructorArgumentValues.ValueHolder 类 型 来 封装 解析 


出 来 的 元 素 。 


(3) 将 type、name 和 index 属 性 一 并 封装 在 
ConstructorArgumentValues.ValueHolder 类 型 中 并 添加 至 当前 
BeanDefinition 的 constructorArgumentValues 的 indexedArgumentValues 属 
性 中 。 

如 果 没 有 指定 index 属 性 ， 那 么 操作 步骤 如 下 。 

(1) 解析 constructor-arg 的 子 元 素 。 

(2) 使 用 ConstructorArgumentValues.ValueHolder 类 型 来 封装 解析 
出 来 的 元 素 。 

(3) 将 type、name 和 index 属 性 一 并 封装 在 
ConstructorArgumentValues.ValueHolder 类 型 中 并 添加 至 当前 
BeanDefinition 的 constructorArgumentValues 的 genericArgumentValues 属 
性 中 。 

可 以 看 到 ， 对 于 是 否 制定 index 属 性 来 讲 ，Spring 的 处 理 流程 是 不 
同 的 ， 关 键 在 于 属性 信息 被 保存 的 位 置 。 
那么 了 解 了 整个 流程 后 ， 我 们 党 试 着 进一步 了 解 解析 构造 函数 配 
置 中 子 元 素 的 过 程 ， 进 入 parsePropertyValue: 
public Object parseProperty Value(Element ele, BeanDefinition bd, 
String propertyName) { 
String elementName = (propertyName !- null) ? 


UU 


"<property> element for property " + propertyName + """ : 


"<constructor-arg> element"; 
/一 个 属性 只 能 对 应 一 种 类 型 : ref. value. list 
NodeList nl = ele.getChildNodes(); 
Element subElement - null; 
for (int i = 0; i < nl.getLength(); i++) ( 
Node node - nl.item(i); 


/对 应 description 或 者 meta 不 处 理 


if (node instanceof Element && !nodeNameEquals(node, 
DESCRIPTION ELEMENT) && 
InodeNameEquals(node, META. ELEMENT)) 1 
if (subElement != null) { 
error(elementName + " must not contain more than one sub- 
element", ele); 
j 
else { 


subElement = (Element) node; 


j 

/解析 constructor-arg 上 的 ref 属 性 

boolean hasRefAttribute = ele.hasAttribute(REF ATTRIBUTE); 

/解析 constructor-arg 上 的 value 属 性 

boolean hasValueAttribute = 
ele.hasAttribute( VALUE ATTRIBUTE); 

if ((hasRefAttribute && hasValueAttribute) || 

((hasRefAttribute || hasValueAttribute) && subElement != null)) 


p 
* 在 constructor-arg 上 不 存在 : 
* ]、 同 时 既 有 ref 属 性 又 有 value 属 性 
* 2、 人 存在 ref 属 性 或 者 value 属 性 且 又 有 子 元 素 
T 

error(elementName + 


" is only allowed to contain either 'ref' attribute OR 'value' 


attribute OR sub-element", ele); 
j 
if (hasRefAttribute) 1 
/ref 属 性 的 处 理 ， 使 用 RuntimeBeanReference 封 装 对 应 的 ref 名 


String refName = ele.getAttribute(REF ATTRIBUTE); 
if (IStringUtils.hasText(refName)) 1 
error(elementName + " contains empty ref attribute", ele); 
j 
RuntimeBeanReference ref = new 
RuntimeBeanReference(refName); 

ref.setSource(extractSource(ele)); 

return ref; 
}else if (hasValueAttribute) { 

//value 属 性 的 处 理 ， 使 用 TypedStringValue 封 装 

TypedStringValue valueHolder = new TypedStringValue 

(ele.getAttribute 

(VALUE_ATTRIBUTE)); 

valueHolder.setSource(extractSource(ele)); 

return valueHolder; 
yelse if (subElement != null) { 

/解析 子 元 素 

return parsePropertySubElement(subElement, bd); 
jelse { 

// 既 没有 ref 也 没有 value 也 没有 子 元 素 ，Spring 蒙 圈 了 

error(elementName + " must specify a ref or value", ele); 


return null; 


j 
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过 程 。 
(1) 上 略 过 description 或 者 meta。 
(2) 提取 constructor-arg 上 的 ref 和 value 属 性 ， 以 便于 根据 规则 验 
证 正确 性 ， 其 规则 为 在 constructor-arg 上 不 存在 以 下 情况 。 
同时 既 有 ref 属 性 又 有 value 属 性 。 
存在 ref 属 性 或 者 value 属 性 且 又 有 子 元 素 。 
(3) ref 属 性 的 处 理 。 使 用 RuntimeBeanReference 封 装 对 应 的 ref 名 
WR, UD: 
«constructor-arg ref="a" > 
(4) value 属 性 的 处 理 。 使 用 TypedStringValue 封 装 ， 例 如 : 
«constructor-arg value="a" > 
(5) 子 元 素 的 处 理 。 例 如 : 
<constructor-arg> 
<map> 
«entry key="key" value="value" /> 
</map> 
</constructor-arg> 
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元 素 map 是 怎么 实现 的 呢 ? parsePropertySubElement 中 实现 了 对 各 种 
子 元 素 的 分 类 处 理 。 
public Object parsePropertySubElement(Element ele, BeanDefinition 
bd) 1 
return parsePropertySubElement(ele, bd, null); 


public Object parsePropertySubElement(Element ele, BeanDefinition 
bd, String defaultValueType) { 
if (!isDefaultNamespace(ele)) 1 
return parseNestedCustomElement(ele, bd); 
j 
else if (nodeNameEquals(ele, BEAN ELEMENT)) 1 
BeanDefinitionHolder nestedBd = 
parseBeanDefinitionElement(ele, bd); 
if (nestedBd !- null) { 
nestedBd = decorateBeanDefinitionIfRequired(ele, nestedBd, 
bd); 
} 
return nestedBd; 
} 
else if (nodeNameEquals(ele, REF ELEMENT)) { 
// A generic reference to any name of any bean. 
String refName = ele.getAttribut(BEAN REF ATTRIBUTE); 
boolean toParent - false; 
if (IStringUtils.hasLength(refName)) { 
/解析 local 
refName = ele.getAttribute(LOCAL REF ATTRIBUTE); 
if (IStringUtils.hasLength(refName)) { 
/解析 parent 
refName = ele.getAttribut(PARENT REF ATTRIBUTE); 
toParent - true; 
if (IStringUtils.hasLength(refName)) { 


error("bean', 'local' or parent is required for <ref> 


element", ele); 


return null; 


} 

if (IStringUtils.hasText(refName)) 1 
error("«ref^ element contains empty target attribute", ele); 
return null; 

} 

RuntimeBeanReference ref = new 

RuntimeBeanReference(refName, toParent); 
ref.setSource(extractSource(ele)); 
return ref; 


} 
/对 idref 元 素 的 解析 
else if (nodeNameEquals(ele, IDREF ELEMENT)) { 
return parseIdRefElement(ele); 
i 
/对 value 子 元 素 的 解析 
else if (nodeNameEquals(ele, VALUE ELEMENT)) 1 
return parseValueElement(ele, defaultValueType); 
j 
/对 null 子 元 素 的 解析 
else if (nodeNameEquals(ele, NULL ELEMENT)) 1 
// It's a distinguished null value. Let's wrap it in a 


TypedString Value 


// object in order to preserve the source location. 
TypedString Value nullHolder = new TypedStringValue(null); 
nullHolder.setSource(extractSource(ele)); 
return nullHolder; 

j 

else if (nodeNameEquals(ele, ARRAY ELEMENT)) { 
/解析 array 子 元 素 
return parseArrayElement(ele, bd); 

j 

else if (nodeNameEquals(ele, LIST ELEMENT)) 1 
// 解 析 list 子 元 素 
return parseListElement(ele, bd); 

j 

else if (nodeNameEquals(ele, SET ELEMENT)) 1 
/解析 set 子 元 素 
return parseSetElement(ele, bd); 

j 

else if (nodeNameEquals(ele, MAP ELEMENT)) { 
/解析 map 子 元 素 
return parseMapElement(ele, bd); 

j 

else if (nodeNameEquals(ele, PROPS_ELEMENT)) { 
/解析 props 子 元 素 
return parsePropsElement(ele); 

j 


else { 


error("Unknown property sub-element: [" + ele.getNodeName() 
4 "vs ele); 


return null; 


j 
可 以 看 到 ， 在 上 面 的 函数 中 实现 了 所 有 可 支持 的 子 类 的 分 类 处 
理 ， 到 这 里 ， 我 们 已 经 大 致 理 清 构造 函数 的 解析 流程 ， 至 于 再 深入 的 
解析 读者 有 兴趣 可 以 目 己 去 探索 。 
7. 解析 子 元 素 property 
parsePropertyElement 东 数 完 成 了 对 property 属 性 的 提取 ，Pproperty 
使 用 方式 如 下 : 
<bean id="test" class="test.TestClass"> 
«property name="testStr" value="aaa"/> 
</bean> 
或 者 
<bean id="a"> 
<property name="p"> 
<list> 
<value>aa</value> 
<value>bb</value> 
</list> 
</property> 
</bean> 
而 具体 的 解析 过 程 如 下 : 
public void parsePropertyElements(Element beanEle, BeanDefinition 
bd) 1 
NodeList nl = beanEle.getChildNodes(); 


for (int i = 0; i < nl.getLength(); i++) ( 
Node node - nl.item(i); 
if (isCandidateElement(node) && nodeNameEquals(node, 


PROPERTY ELEMENT)) { 
parsePropertyElement((Element) node, bd); 


) 
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是 提取 所 有 property 的 子 元 素 ， 然 后 调用 parsePropertyElement 处 理 ， 
parsePropertyElement 代 码 如 下 : 
public void parsePropertyElement(Element ele, BeanDefinition bd) { 


/获取 配置 元 素 中 name 的 值 
String propertyName = ele.getAttribute(NAME ATTRIBUTE); 
if (IStringUtils.hasLength(propertyName)) { 
error("Tag 'property' must have a 'name' attribute", ele); 


return; 


j 
this.parseState.push(new Property Entry(propertyName)); 
try { 
/不 允许 多 次 对 同一 属性 配置 
if (bd.getProperty Values().contains(propertyName)) 1 
error(" Multiple 'property' definitions for property "' + 
propertyName + ™", ele); 
return; 


j 
Object val = parseProperty Value(ele, bd, propertyName); 


Property Value pv = new Property Value(propertyName, val); 
parseMetaElements(ele, pv); 
pv.setSource(extractSource(ele)); 
bd.getProperty Values().addProperty Value(pv); 

j 

finally { 
this.parseState.pop(); 


} 
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属性 中 。 

8. 解析 子 元 素 qualifier 

对 于 qualifier 元 素 的 获取 ， 我 们 接触 更 多 的 是 注解 的 形式 ， 在 使 用 
Spring 框架 中 进行 自动 注入 时 ，Spring 容 器 中 匹配 的 候选 Bean 数 目 必 须 
有 且 仅 有 一 个 。 当 找 不 到 一 个 匹配 的 Bean 时 ， Spring 容器 将 抛 出 
BeanCreationException 异 单 ， 并 指出 必须 至 少 拥有 一 个 匹配 的 Bean。 

Spring 人 允许 我 们 通过 Qualifier 指 定 注 入 Bean 的 名 称 ， 这 样 歧义 就 消 
除了 ， 而 对 于 配置 方式 使 用 如 : 

<bean id="myTestBean" class="bean.MyTestBean"> 

<qualifier 
type="org.Springframework.beans.factory.annotation. Qualifier" 
value="qf"/> 

</bean> 


其 解析 过 程 与 之 前 大 同 小 异 ， 这 里 不 再 重复 叙述 。 
3.1.2 AbstractBeanDefinition 属 性 


至 此 我 们 便 完成 了 对 XML 文档 到 GenericBeanDefinition 的 转换 ， 

也 就 是 说 到 这 里 ，XML 中 所 有 的 配置 都 可 以 在 GenericBeanDefinition 
的 实例 类 中 找到 对 应 的 配置 。 

GenericBeanDefinition 只 是 子 类 实现 ， 而 大 部 分 的 通用 属性 都 保存 
在 了 AbstractBeanDefinition 中 ， 那 么 我 们 再 次 通过 
AbstractBeanDefinition 的 属性 来 回顾 一 下 我 们 都 解析 了 哪些 对 应 的 配 
Bio 

public abstract class AbstractBeanDefinition extends 
BeanMetadataAttributeAccessor 


implements BeanDefinition, Cloneable { 
// 此 处 省 略 静 态 变 量 以 及 final 常 量 


/ 米 米 
* bean 的 作用 范围 ,对 应 bean 属 性 scope 
"i 
private String scope - SCOPE DEFAULT; 
/ 米 米 
* 是 否 是 单 例 ,来 自 bean 属 性 scope 
m 
private boolean singleton = true; 
/ 米 米 
* 是 否 是 原型 ,来 目 bean 属 性 scope 
"i 
private boolean prototype - false; 
/ 米 米 
* 是 否 是 抽象 ， 对 应 bean 属 性 abstract 
S 


private boolean abstractFlag = false; 


/ 米 米 
* 是 否 延迟 加 载 ,对 应 bean 属 性 lazy-init 
"ur 


private boolean lazylInit = false; 


fe 
* 自动 注入 模式 ,对 应 bean 属 性 autowire 
oF 
private int autowireMode = AUTOWIRE_NO; 
[ee 
*+ 依 赖 检 查 ，Spring 3.0 后 弃 用 这 个 属性 
^ 
private int dependencyCheck = DEPENDENCY CHECK. NONE; 
[e 


* 用 来 表示 一 个 bean 的 实例 化 依靠 另 一 个 bean 先 实例 化 ,对 应 
bean 属 性 depend-on 
*/ 
private String[] dependsOn; 


/炒米 
* autowire-candidate 属 性 设置 为 false， 这 样 容 器 在 查找 自动 装配 
对 象 时 ， 


* 将 不 考虑 该 bean， 即 它 不 会 被 考虑 作为 其 他 bean 自 动 装配 的 候 
选 者 ， 但 是 该 bean 本 身 还 是 可 以 使 用 自动 
装配 来 注入 其 他 bean 的 。 
* 对 应 bean 属 性 autowire-candidate 
*/ 
private boolean autowireCandidate = true; 


/炒米 


* 自动 装配 时 当 出 现 多 个 bean 候 选 者 时 ， 将 作为 首选 者 ,对 应 
bean 属 性 primary 
*/ 
private boolean primary = false; 
/炒米 
* 用 于 记录 Qualifier， 对 应 子 元 素 qualifier 
*/ 
private final Map<String, AutowireCandidateQualifier> qualifiers = 


new LinkedHash Map<String, AutowireCandidateQualifier>(0); 


/炒米 
* 允许 访问 非 公 开 的 构造 器 和 方法 ， 程 序 设置 
2 


private boolean nonPublicAccessAllowed = true; 
n 
* SOU MRM MMS, EAIAJJtrue, 
* 如 果 为 false, 则 在 如 下 情况 
* interface ITest{ } 
* class ITestImpl implements ITest{ }; 
* class Main{ 
* Main(ITest i){ } 
* Main(ITestImpl i){ } 


*} 

* 抛 出 异常 ， 因 为 Spring 无 法 准确 定位 哪个 构造 函数 
* 程序 设置 

ia 


private boolean lenientConstructorResolution = true; 


/炒米 


* 记录 构造 函数 注入 属性 ， 对 应 bean 属 性 constructor-arg 
*/ 
private ConstructorArgumentValues constructorArgumentValues; 
/炒米 
* 普通 属性 集合 
"y 
private MutableProperty Values property Values; 


/炒米 


* 方法 重 写 的 持 有 者 ,记录 lookup-method、replaced-method 


*/ 
private MethodOverrides methodOverrides = new 
MethodOverrides(); 
/炒米 
* 对 应 bean 属 性 factory-bean， 用 法 : 
* <bean id="instanceFactoryBean" 
class="example.chapter3.InstanceFactoryBean"/> 
* <bean id="currentTime" factory- 
bean="instanceFactoryBean" factory-method=" 
create Time"/> 
e 
private String factoryBeanName; 
/炒米 
* 对 应 bean 属 性 factory-method 
"y 
private String factoryMethodName; 


/炒米 


* 初始 化 方法 ， 对 应 bean 属 性 init-method 
*/ 
private String initMethodName; 
/炒米 
* 销毁 方法 ， 对 应 bean 属 性 destory-method 
*/ 
private String destroyMethodName; 
[** 
* 是否 执 行 init-method， 程 序 设置 
x 
private boolean enforceInitMethod = true; 
/炒米 
* 是 否 执行 destory-method， 程 序 设置 
*/ 
private boolean enforceDestroyMethod = true; 
/炒米 
* 是 否 是 用 户 定义 的 而 不 是 应 用 程序 本 身 定义 的 ,创建 AOP 
时 候 为 tue， 程 序 设置 
*/ 
private boolean synthetic = false; 
/炒米 
* 定义 这 个 bean 的 应 用 , APPLICATION: 用 户 ， 
INFRASTRUCTURE: 完全 内 部 使 用 ， 与 用 户 无 关 ，SUPPORT: 
某 些 复杂 配置 的 一 部 分 
* 程序 设置 
i 
private int role = BeanDefinition.ROLE APPLICATION; 


/ 米 米 


* bean 的 描述 信息 
*/ 
private String description; 
[** 
* 这 个 bean 定 义 的 资源 
*/ 
private Resource resource; 
/此 处 省 略 seVget 方 法 


到 这 里 我 们 已 经 完成 了 分 析 默 认 标签 的 解析 与 提取 过 程 ， 或 许 涉 
及 的 内 容 太 多 ， 我 们 已 经 所 了 我 们 从 哪个 函数 开始 的 了 ， 我 们 再 次 回 
顾 下 默认 标签 解析 阔 数 的 起 始 冰 效 : 
protected void processBeanDefinition(Element ele, 
BeanDefinitionParserDelegate delegate) 1 
BeanDefinitionHolder bdHolder = 
delegate.parseBeanDefinitionElement(ele); 
if (bdHolder != null) { 
bdHolder - delegate.decorateBeanDefinitionIfRequired(ele, 
bdHolder); 
try { 
// Register the final decorated instance. 
BeanDefinitionReaderUtils.registerBeanDefinition(bdHolder, 
getReader 
Context().getRegistry()); 


j 
catch (BeanDefinitionStoreException ex) ( 
getReaderContext().error(" Failed to register bean definition 
with name ”+ 
bdHolder.getBeanName() + """, ele, ex); 
j 
// Send registration event. 
getReaderContext().fireComponentRegistered(new 
BeanComponentDefinition 
(bdHolder)); 
j 
j 
我 们 已 经 用 了 大 量 的 篇 幅 分 析 了 BeanDefinitionHolder bdHolder = 
delegate.parseBean DefinitionElement(ele) 这 人 句 代 码 ， 接 下 来 ， 我 们 要 进 
行 bdHolder = delegate.decorateBean DefinitionIfRequired(ele, bdHolder) 
代码 的 分 析 ， 首 先 大 致 了 解 下 这 人 句 代 码 的 作用 ， 其 实 我 们 可 以 从 语义 
上 分 析 : 如 果 需 要 的 话 就 对 beanDefinition 进 行 装 饰 ， 那 这 句 代 码 到 底 
是 什么 功能 呢 ? 其 实 这 句 代 码 适用 于 这 样 的 场景 ， 如 : 
<bean id="test" class="test.MyClass"> 
<mybean:user username="aaa"/> 
</bean> 
当 Spring 中 的 bean 使 用 的 是 默认 的 标签 配置 ， 但 是 其 中 的 子 元 素 
却 使 用 了 自 定义 的 配置 时 ， 这 人 句 代码 便 会 起 作用 了 。 可 能 有 人 会 有 疑 
问 ， 之 前 讲 过 ， 对 bean 的 解析 分 为 两 种 类 型 ， 一 种 是 默认 类 型 的 解 
析 ， 另 一 种 是 自 定义 类 型 的 解析 ， 这 不 正 是 自 定 义 类 型 的 解析 吗 ? A 
什么 会 在 默认 类 型 解析 中 单独 添加 一 个 方法 处 理 呢 ? 确实 ， 这 个 问题 
很 让 人 迷惑 ， 但 是 ， 不 知道 聪明 的 读者 是 否 有 发 现 ， 这 个 自 定 义 类 型 


并 不 是 以 Bean 的 形式 出 现 的 呢 ? 我 们 之 前 讲 过 的 两 种 类 型 的 不 同 处 
理 只 是 针对 Bean 的 ， 这 里 我 们 看 到 ， 这 个 自 定义 类 型 其 实 是 属性 。 
好 了 ， 我 们 继续 分 析 下 这 上段 代码 的 逻辑 。 
public BeanDefinitionHolder 
decorateBeanDefinitionIfRequired(Element ele, BeanDefinitionHolder 
definitionHolder) 1 
return decorateBeanDefinitionIfRequired(ele, definitionHolder, 
null); 
j 
这 里 将 函数 中 第 三 个 参数 设置 为 空 ， 那 么 第 三 个 参数 是 做 什么 用 
的 呢 ? 什么 情况 下 不 为 空 呢 ? 其 实 这 第 三 个 参数 是 父 类 bean ， 当 对 某 
个 谋 套 配置 进行 分 析 时 ， 这 里 需要 传递 父 类 beanDefinition。 分 析 源 码 
得 知 这 里 传递 的 参数 其 实 是 为 了 使 用 父 类 的 scope 属 性 ， 以 备 子 类 若 没 
有 设置 scope 时 默认 使 用 父 类 的 属性 ， 这 里 分 析 的 是 顶层 配置 ， 所 以 传 
递 null。 将 第 三 个 参数 设置 为 空 后 进一步 跟踪 孙 数 : 
public BeanDefinitionHolder decorateBeanDefinitionIfRequired( 
Element ele, BeanDefinitionHolder definitionHolder, 
BeanDefinition containingBd) { 
BeanDefinitionHolder finalDefinition = definitionHolder; 
NamedNodeMap attributes = ele.getAttributes(); 
/遍历 所 有 的 属性 ， 看 看 是 否 有 适用 于 修饰 的 属性 
for (int i = 0; i < attributes.getLength(); i++) { 
Node node = attributes.item(i); 
finalDefinition =decoratelfRequired(node, finalDefinition, 
containingBd); 
j 
NodeList children = ele.getChildNodes(); 


/遍历 所 有 的 子 节 点， 看 看 是 否 有 适用 于 修饰 的 子 元 素 
for (int i = 0; i < children.getLength(); i++) { 
Node node = children.item(i); 
if (node.getNodeType() == Node.ELEMENT NODE) { 
finalDefinition -decorateIfRequired(node, finalDefinition, 
containingBd); 
} 
} 
return finalDefinition; 
} 
上 面 的 代码 ， 我 们 看 到 立 数 分 别 对 元 素 的 所 有 属性 以 及 子 节 扣 进 
{T T decorateIfRequired 孙 数 的 调用 ， 我 们 继续 跟踪 代码: 
private BeanDefinitionHolder decorateIfRequired( 
Node node, BeanDefinitionHolder originalDef, BeanDefinition 
containingBd) 1 
// 获 取 自 定义 标签 的 命名 空间 
String namespaceUri = getNamespaceURI(node); 
// 对 于 非 默 认 标 签 进行 修饰 
if ('isDefaultNamespace(namespaceUri)) { 
/根据 命名 空间 找到 对 应 的 处 理 器 
NamespaceHandler handler = this.readerContext. 
getNamespaceHandler Resolver(). 
resolve(namespaceUri); 
if (handler != null) { 
/进行 修饰 
return handler.decorate(node, originalDef, new 


ParserContext(this.readerContext, 


this, containingBd)); 
j 
else if (namespaceUri != null && 
namespaceUri.startsWith(" http: //www. 
Springframework.org/")) { 
error("Unable to locate Spring NamespaceHandler for XML 
schema namespace 
[" * namespaceUri - "|", node); 
j 
else { 


// A custom namespace, not to be handled by Spring - maybe 


if (logger.isDebugEnabled()) { 
logger.debug("No Spring NamespaceHandler found for 
XML schema 


namespace [" + namespaceUri + "|"); 


j 
return originalDef; 
j 
public String getNamespaceURI(Node node) 1 
return node.getNamespaceURI(); 
j 
public boolean isDefaultNamespace(String namespaceUri) { 
//IBEANS NAMESPACE URI = 


"http://www.Springframework.org/schema/beans"; 


return (!StringUtils.hasLength(namespaceUri) || 
BEANS NAMESPACE URI.equals 
(namespaceUri)); 
j 
程序 走 到 这 里 ， 条 理 其 实 已 经 非常 清楚 了 ， 首 先 获取 属性 或 者 元 
素 的 命名 空间 ， 以 此 来 判断 该 元 素 或 者 属性 是 否 适用 于 自 定义 标签 的 
解析 条 件 ， 找 出 自 定义 类 型 所 对 应 的 NamespaceHandler 并 进行 进一步 
解析 。 在 自 定义 标签 解析 的 章节 我 们 会 重点 讲解 ， 这 里 暂时 先 略 过 。 
我 们 总 结 下 decorateBeanDefinitionIfRequired 方 法 的 作用 ， 在 
decorateBeanDefinitionIfRequired 中 我 们 可 以 看 到 对 于 程序 默认 的 标签 
mans 是 直接 略 过 的 ， 因 为 默认 的 标签 到 这 里 已 经 被 处 理 完了 ， 
只 对 自 定义 的 标签 或 者 说 对 bean 的 自 定 义 属 性 感 兴 趣 。 在 方法 中 
Wei itti 并 根据 自 定义 标签 寻找 命名 空间 处 理 器 ， 并 进 
行进 一 步 的 解析 。 


3.1.4 7 BeanDefinition 


对 于 配置 文件 ， 解 析 也 解析 完了 ， 装 饰 也 装饰 完了 ， 对 于 得 到 的 
beanDinition 已 经 可 以 满足 后 续 的 使 用 要 求 了 ， 唯 一 还 剩 下 的 工作 就 是 
注册 了 ， 也 就 是 processBeanDefinition 饭 | 数 中 的 
BeanDefinitionReaderUtils.registerBeanDefinition(bdHolder, 
getReaderContext().getRegistry())f 53 BJ REAIT T o 

public static void registerBeanDefinition( 

BeanDefinitionHolder definitionHolder, BeanDefinitionRegistry 
registry) 

throws BeanDefinitionStoreException { 

/使 用 beanName 做 唯一 标识 注册 


String beanName = definitionHolder.getBeanName(); 


registry.registerBeanDefinition(beanName, 
definitionHolder.getBeanDefinition()); 
/注册 所 有 的 别名 
String[] aliases = definitionHolder.getAliases(); 
if (aliases != null) { 
for (String aliase : aliases) { 


registry.registerAlias(beanName, aliase); 


} 

从 上 面 的 代码 可 以 看 出 ， 解 析 的 beanDefinition 都 会 被 注册 到 
BeanDefinitionRegistry 类 型 的 实例 registry 中 ， 而 对 于 beanDefinition 的 
注册 分 成 了 两 部 分 : 通过 beanName 的 注册 以 及 通过 别名 的 注册 。 

1。 通 过 beanName 注 册 BeanDefinition 

对 于 beanDefinition 的 注册 ， 或 许 很 多 人 认为 的 方式 就 是 将 
beanDefinition 直接 放 入 map 中 就 好 了 ， 使 用 beanName 作为 key。 确 
Sc, Spring 就 是 这 么 做 的 ， 只 不 过 除 此 之 外 ， 它 还 做 了 点 别 的 事情 。 

public void registerBeanDefinition(String beanName, BeanDefinition 
beanDefinition) 

throws BeanDefinitionStoreException 1 

Assert.hasText(beanName, "Bean name must not be empty"); 
Assert.notNull(beanDefinition, "BeanDefinition must not be null"); 
if (beanDefinition instanceof AbstractBeanDefinition) 1 
try { 
/* 
* 注册 前 的 最 后 一 次 校 验 ， 这 里 的 校 验 不 同 于 之 前 的 
XML 文件 校 验 ， 


* 主要 是 对 于 AbstractBeanDefinition 属 性 中 的 
methodOverrides 校 验 ， 
* 校 验 methodOverrides 是 否 与 工厂 方法 并 存 或 者 
methodOverrides 对 应 的 方法 根本 不 存在 
*/ 
((AbstractBeanDefinition) beanDefinition).validate(); 
} 
catch (BeanDefinition ValidationException ex) { 
throw new BeanDefinitionStoreException (beanDefinition. 
getResource 
Description(), beanName, 


"Validation of bean definition failed", ex); 


} 
/因为 beanDefinitionMap 是 全 局 变量 ， 这 里 定 会 存在 并 发 访问 的 


synchronized (this.beanDefinitionMap) { 
Object oldBeanDefinition = 
this.beanDefinitionMap.get(beanName); 
// 处 理 注册 已 经 注册 的 beanName 情 况 
让 (oldBeanDefinition != null) { 
// 如 果 对 应 的 BeanName 已 经 注册 且 在 配置 中 配置 了 bean 不 
允许 被 覆盖 ， 则 抛 出 异常 。 
if (!this.allowBeanDefinitionOverriding) { 
throw new BeanDefinitionStoreException(beanDefinition. 
getResource 


Description(), beanName, 


"Cannot register bean definition [" + beanDefinition + 

"] for bean " + beanName + 

"': There is already [" + oldBeanDefinition + "] bound."); 

jelse 1 

if (this.logger.isInfoEnabled()) 1 

this.logger.info("Overriding bean definition for bean "+ 
beanName + 

"': replacing [" + oldBeanDefinition + "] with [" 


+ beanDefinition + "]"); 


} 
jelse { 
/记录 beanName 
this.beanDefinitionNames.add(beanName); 
this.frozenBeanDefinitionNames - null; 
j 
I 7X BB beanDefinition 
this.beanDefinitionMap.put(beanName, beanDefinition); 
i 
/ 重 置 所 有 beanName 对 应 的 缓存 
resetBeanDefinition(beanName); 
j 
上 面 的 代码 中 我 们 看 到 ， 在 对 于 bean 的 注册 处 理 方式 上 ， 主 要 进 
行 了 几 个 步骤 。 
(1) 对 AbstractBeanDefinition 的 校 验 。 在 解析 XML 文件 的 时 候 我 
们 提 过 校 验 ， 但 是 此 校 验 非 彼 校 验 ， 之 前 的 校 验 时 针对 于 XML 格式 


的 校 验 ， 而 此 时 的 校 验 时 针 是 对 于 AbstractBean Definition 的 
methodOverrides 属 性 的 。 
(2) 对 beanName 已 经 注册 的 情况 的 处 理 。 如 果 设 置 了 不 允许 
beanBy zm, WBBWHOFAS, GUESS. 
(3) 加 入 map 缓 存 。 
(4) 清除 解析 之 前 留 下 的 对 应 beanName 的 缓存 。 
2。 通 过 别名 注册 BeanDefinition 
在 理解 了 注册 bean 的 原理 后 ， 理 解 注册 别名 的 原理 就 容易 多 了 。 
public void registerAlias(String name, String alias) { 
Assert.hasText(name, "name' must not be empty"); 


"n 


Assert.hasText(alias, "alias' must not be empty"); 

/如 果 beanName 与 alias 相 同 的 话 不 记录 alias, 并 删除 对 应 的 alias 

if (alias.equals(name)) { 
this.aliasMap.remove(alias); 

jelse { 
/如 果 alias 不 允许 被 覆盖 则 抛 出 异常 
if (lallowAliasOverriding()) { 
String registeredName = this.aliasMap.get(alias); 


if (registeredName != null && !registeredName.equals(name)) 


throw new IllegalStateException("Cannot register alias "' + 
alias 

+ '™ for name ™ + 

name + "": It is already registered for name "+ 


registeredName + "'."); 


/ 当 A->B 存 在 时 ， 若 再 次 出 现 A->C->B 时 候 则 会 抛 出 异常 
checkForAliasCircle(name, alias); 


this.aliasMap.put(alias, name); 


} 

由 以 上 代码 中 可 以 得 知 注册 alias 的 步骤 如 下 。 

(1) alias 与 beanName 相 同情 况 处理 。 若 alias 与 beaanName 并 名 称 
相同 则 不 需要 处 理 并 删除 掉 原 有 alias。 

(2) alias 履 盖 处 理 。 若 aliasName 已 经 使 用 并 已 经 指向 了 另 一 
beanName 则 需要 用 户 的 设置 进行 处 理 。 

(3) alias 循 环 检查 。 当 A->B 存 在 时 ， 若 再 次 出 现 A->C->B 时 候 则 
会 抛 出 异常。 

(4) 注册 alias。 


通过 代码 getReaderContext().fireComponentRegistered(new 
BeanComponentDefinition(bdHolder)) 完 成 此 工作 ， 这 里 的 实现 只 为 扩 
展 ， 当 程序 开发 人 员 需 要 对 注册 BeanDefinition 事 件 进行 监听 时 可 以 通 
过 注册 监听 器 的 方式 并 将 处 理 逻 辑 写 入 监听 器 中 ， 目 前 在 Spring 中 并 
没有 对 此 事件 做 任何 逻辑 处 理 。 


3.2 alias 标 签 的 解析 


通过 上 面 较 长 的 篇 幅 我 们 终于 分 析 完 了 默认 标签 中 对 bean 标签 的 
处 理 ， 那 么 我 们 之 前 提 到 过 ， 对 配置 文件 的 解析 包括 对 import 标 签 、 
alias 标 签 、bean 标 签 、beans 标 签 的 处 理 ， 现 在 我 们 已 经 完成 了 最 重要 
也 是 最 核心 的 功能 ， 其 他 的 解析 步骤 也 都 是 围绕 第 3 个 解析 而 进行 的 。 
在 分 析 了 第 3 个 解析 步骤 后 ， 再 回 过 头 来 看 看 对 alias 标 签 的 解析 。 


在 对 bean 进 行 定义 时 ， 除 了 使 用 id 属 性 来 指定 名 称 之 外 ， 为 了 提 
供 多 个 名 称 ， 可 以 使 用 alias 标 签 来 指定 。 而 所 有 的 这 些 名 称 都 指向 同 
一 个 bean， 在 某 些 情况 下 提供 别名 非常 有 用 ， 比 如 为 了 让 应 用 的 每 一 
个 组 件 能 更 容易 地 对 公共 组 件 进行 引用 。 

然而 ， 在 定义 bean 时 就 指定 所 有 的 别名 并 不 是 总 是 恰当 的 。 有 时 
我 们 期 望 能 在 当前 位 置 为 那些 在 别处 定义 的 bean 引入 别名 。 在 XML 
配置 文件 中 ， 可 用 单独 的 <alias/> 元 素来 完成 bean 别 名 的 定义 。 如 配置 
文件 中 定义 了 一 个 JavaBean: 

<bean id="testBean" class="com.test"/> 

要 给 这 个 JavaBean 增 加 别名 ， 以 方便 不 同 对 象 来 调用 。 我 们 就 可 
以 直接 使 用 bean 标 签 中 的 name 属 性 : 

<bean id="testBean" name="testBean,testBean2" class="com.test"/> 

同样 ，Spring 还 有 另外 一 种 声明 别名 的 方式 : 

<bean id="testBean" class-"com.test"/7 

<alias name="testBean" alias="testBean,testBean2"/> 

考虑 一 个 更 为 具体 的 例子 ， 组 件 A XML 配置 文件 中 定义 了 一 
个 名 为 componentA 的 DataSource 类 型 的 bean， 但 组 件 B 却 想 在 其 XML 
文件 中 以 componentB 命 名 来 引用 此 bean。 而 且 在 主 程序 MyApp 的 XML 
配置 文件 中 ， 希 望 以 myApp 的 名 字 来 引用 此 bean。 最 后 容器 加 载 3 个 
XML 文件 来 生成 最 终 的 ApplicationContexte。 在 此 情形 下 ， 可 通过 在 配 
置 文件 中 添加 下 列 alias 元 素来 实现 : 

«alias name="componentA" alias="componentB"/> 

«alias name="componentA" alias-"myApp" /> 

这 样 一 来 ， 每 个 组 件 及 主 程序 就 可 通过 唯一 名 字 来 引用 同一 个 数 
据 产 而 互 不 干扰 。 

在 之 前 的 章节 已 经 讲 过 了 对 于 bean 中 name 元 素 的 解析 ， 那 么 我 们 
现在 再 来 深入 分 析 下 对 于 alias 标 签 的 解析 过 程 。 


protected void processAliasRegistration(Element ele) { 


/获取 beanName 
String name = ele.getAttribute(NAME ATTRIBUTE); 
// 获 取 alias 


String alias = ele.getAttribute(ALIAS ATTRIBUTE); 
boolean valid = true; 
if (!StringUtils.hasText(name)) 1 
getReaderContext().error("Name must not be empty", ele); 
valid - false; 
j 
if (!StringUtils.hasText(alias)) { 
getReaderContext().error(" Alias must not be empty", ele); 
valid = false; 
} 
if (valid) { 
try { 
// 注 册 alias 
getReaderContext().getRegistry().registerAlias(name, alias); 
j 
catch (Exception ex) 1 
getReaderContext().error(" Failed to register alias "' + alias + 
"' for bean with name " + name + """, ele, ex); 
i 
/别名 注册 后 通知 监听 器 做 相应 处 理 
getReaderContext().fireAliasRegistered(name, alias, 
extractSource(ele)); 


} 


} 
可 以 发 现 ， 跟 之 前 讲 过 的 bean 中 的 alias 解 析 大 同 小 异 ， 都 是 将 别 
名 与 beanName 组 成 一 对 注册 至 registry 中 。 这 里 不 再 歼 述 。 


3.3 import 标 签 的 解析 


对 于 Spring 配置 文件 的 编写 ， 我 想 ， 经 历 过 庞大 项 目的 人 ， 都 有 
那 种 您 惧 的 心理 ， 太 多 的 配置 文件 了 。 不 过 ， 分 模块 是 大 多 数 人 能 想 
到 的 方法 ， 但 是 ， 怎 么 分 模块 ， 那 融 仁 者 见 仁 ， 智 者 见 知 了。 使 用 
import 是 个 好 办 法 ， 例 如 我 们 可 以 构造 这 样 的 Spring 配置 文件 : 


applicationContext.xml 


<?xml version="1.0" encoding="gb2312"?> 
«IDOCTYPE beans PUBLIC "-//Spring//DTD BEAN//EN" 
"http://www. Springframework.org/ 
dtd/Spring-beans.dtd"> 
<beans> 
«import resource-"customerContext.xml" /> 
«import resource="systemContext.xml" /> 
</beans> 
applicationContext.xml 文 件 中 使 用 import 的 方式 导入 有 模块 配置 文 
件 ， 以 后 若 有 新 模块 的 加 入 ， 那 就 可 以 简单 修改 这 个 文件 了 。 这 样 大 
大 简化 了 配置 后 期 维护 的 复杂 度 ， 并 使 配置 模块 化 ， 易 于 管理 。 我 们 
来 看 看 Spring 是 如 何 解 析 import 配 置 文 件 的 呢 ? 
protected void importBeanDefinitionResource(Element ele) { 
/获取 resource 属 性 
String location = ele.getAttribute(RESOURCE ATTRIBUTE); 


/如 果 不 存 在 resource 属 性 则 不 做 任何 处 理 
if (IStringUtils.hasText(location)) 1 


getReaderContext().error(" Resource location must not be 
empty", ele); 


return; 
j 
/解析 系统 属性 ， 格 式 如 : "$f{user.dir}" 
location = environment.resolveRequiredPlaceholders(location); 
Set<Resource> actualResources = new LinkedHashSet<Resource> 
(4); 
/判定 location 是 决定 URI 还 是 相对 URI 
boolean absoluteLocation = false; 
try { 


absoluteLocation = ResourcePatternUtils.isUrl(location) || 
ResourceUtils.toURI 


(location).isAbsolute(); 
j 
catch (URISyntaxException ex) 1 
// cannot convert to an URI, considering the location relative 


// unless it is the well-known Spring prefix "classpath*:" 


| 
// Absolute or relative? 
// 如 果 是 绝对 URI 则 直接 根据 地 址 加 载 对 应 的 配置 文件 
if (absoluteLocation) { 
try { 
int importCount = 


getReaderContext().getReader().loadBeanDefinitions 


(location, actualResources); 
if (logger.isDebugEnabled()) 1 
logger.debug(" Imported " + importCount + " bean 
definitions from 


URL location [" + location + "]"); 


} 

catch (BeanDefinitionStoreException ex) { 
getReaderContext().error( 
"Failed to import bean definitions from URL location [" + 


location + "|", ele, ex); 


} 
else { 
/如 果 是 相对 地 址 则 根据 相对 地 址 计算 出 绝对 地 址 
try { 


int importCount; 

//Resource 存 在 多 个 子 实现 类 ， 如 VfsResource、 
FileSystemResource 等 ， 

/而 每 个 resource 的 createRelative 方 式 实现 都 不 一 样 ， 所 以 
这 里 先 使 用 子 类 的 方法 

尝试 解析 

Resource relativeResource = getReaderContext(). 
getResource(). Create 

Relative(location); 


if (relativeResource.exists()) 1 


importCount = getReaderContext().getReader(). 
loadBeanDefinitions 
(relativeResource); 
actualResources.add(relativeResource); 
jelse 1 
/如 果 解 析 不 成 功 ， 则 使 用 默认 的 解析 器 
ResourcePatternResolver 进 行 解析 
String baseLocation = 
getReaderContext().getResource().getURI (). 
toString(); 
importCount = 
getReaderContext().getReader().loadBeanDefinitions( 
String Utils.applyRelativePath(baseLocation, location), 
actualResources); 
} 
if (logger.isDebugEnabled()) { 
logger.debug(" Imported " + importCount + " bean 
definitions from 


relative location [" + location + "]"); 


j 
catch (IOException ex) 1 
getReaderContext().error(" Failed to resolve current resource 
location", ele, ex); 
j 


catch (BeanDefinitionStoreException ex) { 


getReaderContext().error(" Failed to import bean definitions 
from 
relative location [" + location + "|", 


ele, ex); 


j 

/解析 后 进行 监听 器 激活 处 理 

Resource[] actResArray = actualResources.toArray(new 
Resource[actualResources. size()]); 

getReaderContext().fireImportProcessed(location, actResArray, 
extractSource(ele)); 

} 

上 面 的 代码 不 难 ， 相 信 配 合 注释 会 很 好 理解 ， 我 们 总 结 一 下 大 致 
流程 便于 读者 更 好 地 梳理 ， 在 解析 <import 标 签 时 ，Spring 进 行 解析 的 
步骤 大 致 如 下 。 

(1) 获取 resource 属 性 所 表示 的 路 径 。 

(2) 解析 路 径 中 的 系统 属性 ， 格 式 如 “${user.dir}”。 

(3) 判定 location 是 绝对 路 径 还 是 相对 路 径 。 

(4) 如 果 是 绝对 路 径 则 递归 调用 bean 的 解析 过 程 ， 进 行 另 一 次 的 
解析 。 

(5) 如 果 是 相对 路 径 则 计算 出 绝对 路 径 并 进行 解析 。 

(6) 通知 监听 器 ， 解 析 完 成 。 


3.4 beans 标 等 


对 于 同 入 式 的 beans 标 签 ， 相 信 大 家 使 用 过 或 者 至 少 接 触 过 ， 非 常 
类 似 于 import 标 签 所 提供 的 功能 ， 使 用 如 下 : 


<?xml version="1.0" encoding="UTF-8"?> 
«beans xmlns-"http://www.Springframework.org/schema/beans" 


xmins:xsi-"http://www.w3.0rg/2001/XMLSchema-instance" 


xsi:schemaLocation="http://www.Springframework.org/schema/beans 
http://www. Springframework. 
org/schema/beans/Spring-beans.xsd"> 
<bean id="aa" class="test.aa"/> 
<beans> 
</beans> 
</beans> 
X FERAT beans 标签 来 讲 ， 并 没有 太 多 可 讲 ， 与 单独 的 配置 文 
件 并 没有 太 大 的 差别 ， 无 非 是 递归 调用 beans 的 解析 过 程 ， 相 信 读 者 
根据 之 前 讲解 过 的 内 容 已 经 有 能 力 理 解 其 中 的 奥秘 了 。 


在 之 前 的 章节 中 ， ais 到 了 在 Spring 中 存在 默认 标 等 与 目 定 义 
标签 两 种 ， 而 在 上 一 章节 中 我 们 分 析 了 Spring 中 对 默认 标签 的 解析 过 
te, HEAR EBL unm. 那么 ， 现 在 将 开始 新 的 里 程 ， 分 析 
Spring 中 自 定 义 标 签 的 加 载 过 程 。 同 样 ， 我 们 还 是 先 再 次 回顾 一 下 ， 
当 完 成 从 配置 文件 到 Document 的 转换 并 提取 对 应 的 root 后 ， aded 
所 有 元 素 的 解析 ， 而 在 这 一 过 程 中 便 开 始 了 默认 标签 与 目 定 义 标 签 
种 格式 的 区 分 ， 阔 效 如 下 : 

protected void parseBeanDefinitions(Element root, 
BeanDefinitionParserDelegate delegate) 1 


if (delegate.isDefaultNamespace(root)) { 


} 


NodeList nl = root.getChildNodes(); 
for (int i = 0; i < nl.getLengthQ); i++) ( 
Node node = nl.item(i); 
if (node instanceof Element) { 
Element ele = (Element) node; 
if (delegate.isDefaultNamespace(ele)) { 
parseDefaultElement(ele, delegate); 
} 
else { 


delegate.parseCustomElement(ele); 


} 


else { 


delegate.parseCustomElement(root); 


在 本 章 中 ， 所 有 的 功能 都 是 围绕 其 中 的 一 名 代码 


delegate.parseCustomElement(roob 开 展 的 。 从 上 面 的 函数 我 们 可 以 看 
出 ， 当 Spring 拿 到 一 个 元 素 时 首先 要 做 的 是 根据 命 


如 果 是 默认 的 命 


4.1 


LY = 
Ày 


间 进 行 解析 ， 
空间 ， 则 使 用 parseDefaultElement 方法 进行 元 素 解 
Nt, AUER parseCustom Element 方法 进行 解析 。 在 分 析 自 定义 标签 
的 解析 过 程 前 ， 我 们 先 了 解 一 下 自 定 义 标 签 的 使 用 过 程 。 


答 


X) 


在 很 多 情况 下 ， 我 们 需要 为 系统 提供 可 配置 化 支持 ， 简 单 的 做 法 
可 以 直接 基于 Spring 的 标准 bean 来 配置 ， 但 配置 较为 复杂 或 者 需要 更 
多 丰富 控制 的 时 候 ， 会 显得 非常 笨拙 。 一 般 的 做 法 会 用 原生 态 的 方式 
去 解析 定义 好 的 XML 文 件 ， 然 后 转化 为 配置 对 象 。 这 种 方式 当然 可 以 
解决 所 有 问题 ， 但 实现 起 来 比较 繁琐 ,特别 是 在 配置 非常 复杂 的 时 
候 ， 解 析 工 作 是 一 个 不 得 不 考虑 的 负担 。Spring 提 供 了 可 扩展 Schema 
的 支持 ， 这 是 一 个 不 错 的 折 中 方案 ， 扩 展 Spring 自 定义 标签 配置 大 致 
需要 以 下 几 个 步骤 《前 提 是 要 把 Spring 的 Core 包 加 入 项 目 中 ) 。 
创建 一 个 需要 扩展 的 组 件 。 
定义 一 个 XSD 文件 换 述 组 件 内 容 。 
创建 一 个 文件 ， 实 现 BeanDefinitionParser 接 口 ， 用 来 解析 XSD 文 
件 中 的 定义 和 组 件 定义 。 
创建 一 个 Handler 文 件 ， 扩 展 自 NamespaceHandlerSupport， 目 的 是 
将 组 件 注 册 到 Spring 容 器 。 
编写 Spring.handlers 和 Spring.schemas 文 件 。 
现在 我 们 就 按照 上 面 的 步 又 带领 读者 一 步 步 地 体验 自 定义 标签 的 
过 程 。 
(1) 首先 我 们 创建 一 个 普通 的 POJO， 这 个 POJO 没有 任何 特别 之 
处 ， 只 是 用 来 接收 配置 文件 。 
package test.customtag; 
public class User { 
private String userName; 
private String email; 
/省 略 setget 方 法 
j 
(2) 定义 一 个 XSD 文件 描述 组 件 内 容 。 


<?xml version-" 1.0" encoding="UTF-8"?> 


«schema xmins-"http://www.w3.0rg/2001/XMLSchema" 
targetNamespace-"http://www.lexueba.com/schema/user" 
xmins:tns-"http://www.lexueba.com/schema/user" 
elementFormDefault-" qualified"? 
<element name="user"> 
<complexType> 
<attribute name="id" type="string"/> 
<attribute name="userName" type="string"/> 
<attribute name="email" type="string"/> 
</complexType> 
</element> 
</schema> 
在 上 面 的 XSD 文件 中 描述 了 一 个 新 的 targetNamespace， 并 在 这 
个 空间 中 定义 了 一 个 name 为 user 的 element，user 有 3 个 属性 id、 
userName 和 email， 其 中 email 的 类 型 为 string。 这 3 个 类 主要 用 于 验证 
Spring 配置 文件 中 自 定 义 格式 。XSD 文 件 是 XML DTD 的 替代 者 ， 使 用 
XML Schema 语言 进行 编号， 这 里 对 XSD Schema 不 做 太 多 解释 ， 有 兴 
趣 的 读者 可 以 参考 相关 的 资料 。 
(3) 创建 一 个 文件 ， 实 现 BeanDefinitionParser 接 口 ， 用 来 解析 
XSD 文件 中 的 定义 和 组 件 定义 。 
package test.customtag; 
Import 
org.Springframework.beans.factory.support.BeanDefinitionBuilder; 
import 
org.Springframework.beans.factory.xml.AbstractSingleBeanDefinitionParse 
T; 


import org.Springframework.util.StringUtils; 


import org.w3c.dom.Element; 
public class UserBeanDefinitionParser extends 
AbstractSingleBeanDefinitionParser { 
/Element 对 应 的 类 
protected Class getBeanClass(Element element) { 
return User.class; 
j 
/从 element 中 解析 并 提取 对 应 的 元 素 
protected void doParse(Element element, BeanDefinitionBuilder 
bean) 1 
String userName = element.getAttribute("userName"); 
String email = element.getAttribute(" email"); 
/将 提取 的 数据 放 入 到 BeanDefinitionBuilder 中 ， 待 到 完成 
所 有 bean 的 解析 后 统一 注册 到 
beanFactory 中 
if (StringUtils.hasText(userName)) { 
bean.addProperty Value("userName'", userName); 
j 
if (StringUtils.hasText(email)) 1 


bean.addProperty Value(" email", email); 


} 
(4) 创建 一 个 Handler 文件 ， 扩 展 自 NamespaceHandlerSupport, 
目的 是 将 组 件 注册 到 Spring 容器 。 


package test.customtag; 


import 
org.Springframework.beans.factory.xml.NamespaceHandlerSupport; 

public class MyNamespaceHandler extends 
NamespaceHandlerSupport 1 

public void init() 1 
registerBeanDefinitionParser("user", new 
UserBeanDefinitionParser()); 
j 

j 

以 上 代码 很 简单 ， 无 非 是 当 遇 到 自 定义 标签 <user:aaa 这 样 类 似 于 
以 user 开 头 的 元 素 ， 就 会 把 这 个 元 素 扔 给 对 应 的 
UserBeanDefinitionParser 去 解析 。 

(5) 编写 Spring.handlers 和 Spring.schemas 文 件 ， 默 认 位 置 是 在 工 

程 的 /META-INEF/ 文 件 夹 下 ， 当 然 ， 你 可 以 通过 Spring 的 扩展 或 者 修改 
源码 的 方式 改变 路 径 。 

Spring.handlerso 

http\://www.lexueba.com/schema/user=test.customtag. MyNamespace 
Handler 

Spring.schemaso 

http\://www.lexueba.com/schema/user.xsd=META-INF/Spring-test.xsd 

到 这 里 ， 自 定义 的 配置 就 结束 了 ， 而 Spring 加 载 自 定 义 的 大 致 流 
程 是 遇 到 自 定 义 标签 然后 就 去 Spring.handlers 和 Spring.schemas 中 去 找 
对 应 的 handler 和 XSD， 默 认 位 置 是 /META-INEF/ 下 ， 进 而 有 找到 对 应 的 
handler 以 及 解析 元 素 的 Parser， 从 而 完成 了 整个 自 定 义 元 素 的 解析 ， 也 
就 是 说 自 定 义 与 Spring 中 默认 的 标准 配置 不 同 在 于 Spring 将 自 定 义 标 
签 解析 的 工作 委托 给 了 用 户 去 实现 。 


(6) 创建 测试 配置 文件 ， 在 配置 文件 中 引入 对 应 的 命名 空间 以 及 
XSD 后 ， 便 可 以 直接 使 用 自 定义 标签 了 。 
«beans xmlns-"http://www.Springframework.org/schema/beans" 
xmins:xsi-"http://www.w3.0rg/2001/XMLSchema-instance" 


xmlns:myname-"http://www.lexueba.com/schema/user" 


xsi:schemaLocation="http://www.Springframework.org/schema/beans 
http://www. 
Springframework.org/schema/beans/Spring-beans-2.0.xsd 

http://www. lexueba.com/schema/user 
http://www. lexueba.com/schema/user.xsd"> 

«myname:user id="testbean" userName="aaa" email="bbb"/> 

</beans> 

(7) 测试 。 
public static void main(String[] args) { 
ApplicationContext bf = new ClassPathXmlApplicationContext 

("test/customtag/ 

test.xml"); 

User user=(User) bf.getBean("testbean"); 

System.out.printIn(user. getUserName()+","+user.getEmail()); 

} 
不 出 意外 的 话 ， 你 应 该 看 到 了 我 们 期 待 的 结果 ， 控 制 台 上 打印 出 

a 

aaa,bbb 

在 上 面 的 例子 中 ， 我 们 实现 了 通过 自 定义 标签 实现 了 通过 属性 的 
方式 将 user 类 型 的 Bean 赋 值 ， 在 Spring 中 自 定 义 标 签 非常 常用 ， 例 如 
我 们 熟知 的 事务 标签 : tx(<tx:annotation-driven>)。 


4.2 x 标签 


了 解 了 自 定义 标签 的 使 用 后 ， 我 们 带 着 强烈 的 好 奇 心 来 探究 一 下 
自 定义 标签 的 解析 过 程 。 
public BeanDefinition parseCustomElement(Element ele) { 
return parseCustomElement(ele, null); 
j 
//containingBd 为 父 类 bean， 对 顶层 元 素 的 解析 应 设置 为 null 
public BeanDefinition parseCustomElement(Element ele, 
BeanDefinition uL { 
/获取 对 应 的 命名 空 
String ee = getNamespaceURI|(ele); 
/根据 命名 空间 找到 对 应 的 NamespaceHandler 
NamespaceHandler handler = 
this.readerContext.getNamespaceHandlerResolver(). 
resolve(namespaceUri); 
if (handler == null) { 
error("Unable to locate Spring NamespaceHandler for XML 
schema namespace [" 
+ namespaceUri + "]", ele); 
return null; 
} 
/调用 自 定 义 的 NamespaceHandler 进 行 解析 
return handler.parse(ele, new ParserContext(this.readerContext, 
this, 
containingBd)); 


相信 了 解 了 自 定义 标签 的 使 用 方法 后 ， 或 多 或 少 会 对 自 定义 标签 
的 实现 过 程 有 一 个 自己 的 想法 。 其 实 思 路 非常 的 简单 ， 无 非 是 根据 对 
应 的 bean 获取 对 应 的 命名 空间 ， 根 据 命 名 空间 解析 对 应 的 处 理 器 ， 然 
后 根据 用 户 自 定义 的 处 理 器 进行 解析 。 可 是 有 些 事情 说 起 来 简单 做 起 
来 难 ， 我 们 先 看 看 如 何 获 取 命 名 空间 吧 。 


4.2.1 示 答 :的 在 E 


标签 的 解析 是 从 命名 空间 的 提起 开始 的 ， 无 论 是 区 分 Spring PEK 
认 标 签 和 自 定 义 标 签 还 是 区 分 自 定 义 标 签 中 不 同 标签 isi inae 
标签 所 提供 的 命名 空间 为 基础 的 ， 而 至 于 如 何 提取 对 应 元 素 的 命 
间 其 实 并 不 需要 我 们 杀 自 去 实现 ， 在 org.w3c.dom.Node 中 已 经 提供 了 
方法 供 我 们 直接 调用 : 

public String getNamespaceURI(Node node) { 

return node.getNamespaceURI(); 
j 


4.2.2 提 x 标签 处 理 


有 了 命名 空间 ， 就 可 以 进行 NamespaceHandler 的 提取 了 ， 继 续 之 
前 的 parseCustomElement 回 数 的 跟踪 ， 分 析 NamespaceHandler handler 
= this.readerContext.getNamespaceHandlerResolver(). 
resolve(namespaceUri)， 在 readerContext 初 始 化 的 时 候 其 属性 
namespaceHandlerResolver 已 经 被 初始 化 为 了 
DefaultNamespaceHandlerResolver 的 实例 ， 所 以 ， 这 里 调用 的 resolve 
方法 其 实 调用 的 是 DefaultNamespaceHandlerResolver 类 中 的 方法 。 我 
们 进入 DefaultNamespaceHandlerResolver 的 resolve 方 法 进行 查看 。 

DefaultNamespaceHandlerResolver.java 


public NamespaceHandler resolve(String namespaceUri) 1 


/获取 所 有 已 经 配置 的 handler 映 射 
Map<String, Object> handlerMappings = getHandlerMappings(); 
/根据 命名 空间 找到 对 应 的 信息 
Object handlerOrClassName = 
handlerMappings.get(namespaceUri); 
if (handlerOrClassName == null) 1 
return null; 
yelse if (handlerOrClassName instanceof NamespaceHandler) ( 
/已 经 做 过 解析 的 情况 ， 直 接 从 缓存 读 取 
return (NamespaceHandler) handlerOrClassName; 
jelse 1 
// 没 有 做 过 解析 ， 则 返回 的 是 类 路 径 
String className = (String) handlerOrClassName; 
try { 
/使 用 反射 将 类 路 径 转化 为 类 
Class«?» handlerClass = ClassUtils.forName(className, 
this.classLoader); 


if (INamespaceHandler.class.isAssignableFrom(handlerClass)) 


throw new FatalBeanException(" Class [" + className + "] 
for 
namespace [" + namespaceUri + 
"| does not implement the [" + NamespaceHandler. class. 
getName() + "] interface"); 
} 
/初始 化 类 


NamespaceHandler namespaceHandler = (NamespaceHandler) 
BeanUtils. 
instantiateClass(handlerClass); 
// 调 用 自 定义 的 NamespaceHandler 的 初始 化 方法 
namespaceHandler.init(); 
/记录 在 缓存 
handlerMappings.put(namespaceUri, namespaceHandler); 
return namespaceHandler; 
jcatch (ClassNotFoundException ex) 1 
throw new FatalBeanException("NamespaceHandler class [" + 
className + 
"| for namespace [" + 
namespaceUri + "| not found", ex); 
jcatch (LinkageError err) 1 


throw new FatalBeanException(" Invalid NamespaceHandler 


class [" * 
className + "] for namespace [" + 
namespaceUri + "]: problem with handler class file or 
dependent 
class", err); 
j 
j 
j 


上 面 的 函数 清晰 地 前 述 了 解析 自 定 义 NamespaceHandler 的 过 程 ， 
通过 之 前 的 示例 程序 我 们 了 解 到 如 果 要 使 用 自 定 义 标签 ， 那 么 其 中 一 
项 必 不 可 少 的 操作 就 是 在 Spring.handlers 文 件 中 配置 命名 空间 与 命名 空 
间 处 理 器 的 映射 关系 。 只 有 这 样 ，Spring 才 能 根据 映射 关系 找到 匹配 


的 处 理 器 ， 而 寻找 匹配 的 处 理 器 就 是 在 上 面 函 数 中 实现 的 ， 当 获取 到 
自 定义 的 NamespaceHandler 之 后 就 可 以 进行 处 理 器 初始 化 并 解析 了 。 
我 们 不 妨 再 次 回忆 一 下 示例 中 对 于 命名 空间 处 理 器 的 内 容 : 
public class MyNamespaceHandler extends 
NamespaceHandlerSupport 1 
public void init() 1 
registerBeanDefinitionParser("user", new 
UserBeanDefinitionParser()); 
j 
} 
当 得 到 自 定义 命名 空间 处 理 后 会 马上 执行 namespaceHandler.init() 
来 进行 自 定 义 Bean DefinitionParser 的 注册 。 在 这 里 ， 你 可 以 注册 多 个 
标签 解析 器 ， 当 前 示例 中 只 有 支持 <myname:user 的 写法 ， 你 也 可 以 在 
这 里 注册 多 个 解析 器 ， 如 <myname:A、<myname:B 等 ， 使 得 myname 的 
命名 空间 中 可 以 支持 多 种 标签 解析 。 
注册 后 ， 命 名 空间 处 理 器 就 可 以 根据 标签 的 不 同 来 调用 不 同 的 解 
析 器 进行 解析 。 那 么 ， 根 据 上 面 的 函数 与 之 前 介绍 过 的 例子 ， 我 们 基 
本 上 可 以 推断 getHandlerMappings 的 主要 功能 就 是 读 取 Spring.handlers 
配置 文件 并 将 配置 文件 缓存 在 map 中 。 
private Map<String, Object> getHandlerMappings() { 
/如 果 没 有 被 缓存 则 开始 进行 缓存 
if (this.handlerMappings == null) { 
synchronized (this) 1 
if (this.handlerMappings == null) { 
try { 
//this.handlerMappingsLocation 在 构造 图 数 中 已 经 被 初 
始 化 为 :META- 


INF/Spring.handlers 


Properties mappings = 
PropertiesLoaderUtils.loadAllProperties (this. 


handlerMappingsLocation, this.classLoader); 
if (logger.isDebugEnabled()) { 


logger.debug("Loaded NamespaceHandler mappings: " 
* mappings); 


} 


Map<String, Object> handlerMappings = new 
ConcurrentHashMap< 


String, Object>(); 


/将 Properties 格 式 文 件 合并 到 Map 格 式 的 
handlerMappings 中 


CollectionUtils.mergePropertiesIntoMap(mappings, 
handlerMappings); 


this.handlerMappings = handlerMappings; 
} 


catch (IOException ex) { 
throw new IllegalStateException( 


"Unable to load NamespaceHandler mappings from 


location [" * this.handlerMappingsLocation - "]", ex); 


} 


return this.handlerMappings; 


同 我 们 想象 的 一 样 ， 借 助 了 工具 类 PropertiesLoaderUtils 对 属性 
handlerMappingsLocation 进 行 了 配置 文件 的 读 取 ， 
handlerMappingsLocation 被 默认 初始 化 为 “META- 
INF/Spring.handlers”o 


得 到 了 解析 器 以 及 要 分 析 的 元 素 后 ，Spring 就 可 以 将 解析 工作 委 
托 给 目 定 义 解析 器 去 解析 了 。 在 Spring 中 的 代码 为 : 

return handler.parse(ele, new ParserContext(this.readerContext, this, 
containingBd)) 

以 之 前 提 到 的 示例 进行 分 析 ， 此 时 的 handler 已 经 被 实例 化 成 为 了 
我 们 自 定 义 的 MyNamespaceHandler 了 ， 而 MyNamespaceHandler 也 已 经 
完成 了 初始 化 的 工作 ， 但 是 在 我 们 实现 的 自 定 义 命名 空间 处 理 器 中 并 
没有 实现 parse 方法 ， 所 以 推断 ， 这 个 方法 是 父 类 中 的 实现 ， 查 看 父 
类 NamespaceHandlerSupport 中 的 parse 方 法 。 

NamespaceHandlerSupport.java 

public BeanDefinition parse(Element element, ParserContext 
parserContext) { 

/寻找 解析 器 并 进行 解析 操作 
returnfindParserForElement(element, 
parserContext).parse(element, parserContext); 
j 

解析 过 程 中 首先 是 寻找 元 素 对 应 的 解析 器 ， 进 而 调用 解析 器 中 的 
parse 方法 ， 那 么 结合 示例 来 讲 ， 其 实 就 是 首先 获取 在 
MyNameSpaceHandler 类 中 的 init 方 法 中 注册 的 对 应 的 UserBean 
DefinitionParser 实 例 ， 并 调用 其 parse 方 法 进行 进一步 解析 。 


private BeanDefinitionParser findParserForElement(Element element, 
ParserContext parser 
Context) 1 
/获取 元 素 名 称 ， 也 就 是 <myname:user 中 的 user 各 在 示例 中 ， 此 
时 localName 为 user 
String localName = 
parserContext.getDelegate().getLocal Name(element); 
/根据 user 找 到 对 应 的 解析 器 ， 也 就 是 在 
//registerBeanDefinitionParser("user", new 
UserBeanDefinitionParser()); 
/注册 的 解析 器 
BeanDefinitionParser parser = this.parsers.get(localName); 
if (parser == null) { 
parserContext.getReaderContext().fatal( 


"Cannot locate BeanDefinitionParser for element [" + localName 


"|", element); 
j 
return parser; 
j 
而 对 于 parse 方 法 的 处 理 : 
public final BeanDefinition parse(Element element, ParserContext 
parserContext) { 
AbstractBeanDefinition definition = parseInternal(element, 
parserContext); 
if (definition != null && !parserContext.isNested()) 1 
try 1 


String id = resolveld(element, definition, parserContext); 
if (!StringUtils.hasText(id)) 1 
parserContext.getReaderContext().error( 


UU 


"Id is required for element " + parserContext. 
getDelegate().getLocalName(element) 
* " when used as a top-level tag", element); 
j 
String[] aliases = new String[0]; 
String name = element.getAttribute(NAME ATTRIBUTE); 
if (StringUtils.hasLength(name)) { 


aliases — 


StringUtils.trimArrayElements(StringUtils.commaDelimitedListToStringAr 


} 
// 将 AbstractBeanDefinition 转 换 为 BeanDefinitionHolder 并 注 


BeanDefinitionHolder holder = new 


BeanDefinitionHolder(definition, id, 


aliases); 
registerBeanDefinition(holder, parserContext.getRegistry()); 
if (shouldFireEvents()) 1 

// 需 要 通知 监听 器 则 进行 处 理 


BeanComponentDefinition componentDefinition = new 


BeanComponent 


Definition(holder); 


postProcessComponentDefinition(componentDefinition); 


parserContext.registerComponent(componentDefinition); 


j 
catch (BeanDefinitionStoreException ex) { 
parserContext.getReaderContext().error(ex.getMessage(), 
element); 


return null; 


j 
return definition; 
j 
虽说 是 对 自 定义 配置 文件 的 解析 ， 但 是 ， 我 们 可 以 看 到 ， 在 这 个 
国 数 中 大 部 分 的 代码 是 用 来 处 理 将 解析 后 的 AbstractBeanDefinition 转 
化 为 BeanDefinitionHolder 并 注册 的 功能 ， 而 真正 去 做 解析 的 事情 委托 
给 了 遂 数 parseInternal， 正 是 这 句 代 码 调 用 了 我 们 自 定义 的 解析 遂 数 。 
在 parseInternal 中 并 不 是 直接 调用 自 定义 的 doParse 孙 数 ， 而 是 进行 
了 一 系列 的 数据 准备 ， 包 括 对 beanClass、scope、lazyInit 等 属性 的 准 
备 。 
protected final AbstractBeanDefinition parseInternal(Element element, 
ParserContext 
parserContext) { 
BeanDefinitionBuilder builder = 
BeanDefinitionBuilder.genericBeanDefinition(); 
String parentName - getParentName(element); 
if (parentName != null) { 


builder.getRawBeanDefinition().setParentName(parentName); 


// 获 取 自 定义 标签 中 的 class， 此 时 会 调用 自 定义 解析 器 如 
UserBeanDefinitionParser 中 的 getBeanClass 
方法 。 
Class<?> beanClass = getBeanClass(element); 
if (beanClass != null) { 


builder.getRawBeanDefinition().setBeanClass(beanClass); 


j 
else { 
/ 若 子 类 没有 重 写 getBeanClass 方 法 则 尝试 检查 子 类 是 否 重 写 
getBeanClassName 方 法 
String beanClassName = getBeanClassName(element); 


if (beanClassName !- null) { 


builder.getRawBeanDefinition().setBeanClassName(beanClassName); 


} 


builder.getRawBeanDefinition().setSource(parserContext.extractSource(ele 
ment)); 

if (parserContext.isNested()) 1 

// 若 存在 父 类 则 使 用 父 类 的 scope 属 性 


builder.setScope(parserContext.getContainingBeanDefinition().getScope()); 
j 
if (parserContext.isDefaultLazylInit()) { 


// Default-lazy-init applies to custom bean definitions as well. 


/配置 延迟 加 载 


builder.setLazyInit(true); 
/调用 子 类 重 写 的 doParse 方 法 进行 解析 
doParse(element, parserContext, builder); 
return builder.getBeanDefinition(); 
i 
protected void doParse(Element element, ParserContext parserContext, 
BeanDefinition 
Builder builder) { 
doParse(element, builder); 
} 
回顾 一 下 全 部 的 自 定义 标签 处 理 过 程 ， 虽 然 在 实例 中 我 们 定义 
UserBeanDefinitionParser， 但 是 在 其 中 我 们 只 是 做 了 与 自己 业务 逻辑 
相 天 的 部 分 。 不 过 我 们 没 做 但 是 并 不 代表 没有 ， 在 这 个 处 理 过 程 中 同 
样 也 是 按照 Spring 中 默认 标签 的 处 理 方式 进行 ， 包 括 创建 
BeanDefinition 以 及 进行 相应 默认 属性 的 设置 ， 对 于 这 些 工 作 Spring 都 
默默 地 帮 我 们 实现 了 ， 只 是 暴露 出 一 些 接口 来 供用 户 实 现 个 性 化 的 业 
务 。 通 过 对 本 章 d 解 ， 相 信 读 者 对 Spring 中 自 定义 标签 的 使 用 以 及 
在 解析 自 定 义 标签 过 程 中 Spring 为 我 们 做 了 哪些 工作 会 有 一 个 全 面 的 
了 解 。 到 此 为 止 我 们 已 经 完成 了 Spring 中 全 部 的 解析 工作 ， 也 就 是 说 
到 现在 为 止 我 们 已 经 理解 了 Spring 将 bean 从 配置 文件 到 加 载 到 内 存 T 
的 全 过 程 ， 而 接 下 来 的 任务 便 是 如 何 使 用 这 些 bean, F—8* 712 
bean 的 加 载 。 
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经 过 前 面 的 分 析 ， 我 们 终于 结束 了 对 XML 配置 文件 的 解析 ， 接 下 
来 将 会 面临 更 大 的 挑战 ， 就 是 对 bean 加 载 的 探索 。bean 加 载 的 功能 实 
现 远 比 bean 的 解析 要 复杂 得 多 ， 同 样 ， 我 们 还 是 以 本 书 开篇 的 示例 为 
基础 ， 对 于 加 载 bean 的 功能 ， 在 Spring 中 的 调用 方式 为 : 
MyTestBean bean=(MyTestBean) bf.getBean("myTestBean") 
这 句 代码 实现 了 什么 样 的 功能 呢 ? 我 们 可 以 先 快速 体验 一 下 
Spring 中 代码 是 如 何 实现 的 。 
public Object getBean(String name) throws BeansException 1 
return doGetBean(name, null, null, false); 
j 
protected <T> T doGetBean( 
final String name, final Class<T> requiredType, final Object[] args, 
boolean 
typeCheckOnly) throws BeansException 1 
/提取 对 应 的 beaanName 
final String beanName = transformedBeanName(name); 
Object bean; 
/* 
* 检查 缓存 中 或 者 实例 工厂 中 是 否 有 对 应 的 实例 
* 为 什么 首先 会 使 用 这 段 代码 呢 ， 
* 因为 在 创建 单 例 bean 的 时 候 会 存在 依赖 注入 的 情况 ， 而 在 
创建 依赖 的 时 候 为 了 避免 循环 依赖 ， 
* Spring 创 建 bean 的 原则 是 不 等 bean 创 建 完成 就 会 将 创建 bean 
的 ObjectFactory 提 早 曝光 
* 也 就 是 将 ObjectFactory 加 入 到 缓存 中 ， 一 旦 下 个 bean 创 建 时 
候 需要 依赖 上 个 bean 则 直接 使 用 
ObjectFactory 


sa) 
/直接 尝试 从 缓存 获取 或 者 singletonFactories 中 的 ObjectFactory 
中 获取 
Object sharedInstance = getSingleton(beanName); 
if (sharedInstance != null && args == null) { 
if (logger.isDebugEnabled()) { 
if (isSingletonCurrentlyInCreation(beanName)) 1 
logger.debug(" Returning eagerly cached instance of 
singleton bean 
" + beanName + 
"that is not fully initialized yet - a consequence of 


a circular reference"); 


} 
else { 
beanName + """); 
logger.debug("Returning cached instance of singleton bean 
ee 
} 
} 


/返回 对 应 的 实例 ， 有 时 候 存 在 诸如 BeanFactory 的 情况 并 不 是 
直接 返回 实例 本 身 而 是 返回 指定 方法 返回 的 实例 
bean = getObjectForBeanInstance(sharedInstance, name, 
beanName, null); 
jelse 1 
/只 有 在 单 例 情况 才 会 尝试 解决 循环 依赖 ， 原 型 模式 情况 
下 ， 如 果 存 在 


/A 中 有 B 的 属性 ，B 中 有 A 的 属性 ， 那 么 当 依赖 注入 的 时 候 ， 
就 会 产生 当 A 还 未 创建 完 的 时 候 因 为 
/对 于 B 的 创建 再 次 返回 创建 A， 造 成 循环 依赖 ， 也 就 是 下 面 
的 情况 
//isPrototypeCurrentlyInCreation(beanName)/Jtrue 
if (isPrototypeCurrentlyInCreation(beanName)) { 
throw new BeanCurrentlyInCreationException(beanName); 
} 
BeanFactory parentBeanFactory = getParentBeanFactory(); 
/如 果 beanDefinitionMap 中 也 就 是 在 所 有 已 经 加 载 的 类 中 不 
包括 beanName 则 尝试 从 
parentBeanFactory 中 检测 
if (parentBeanFactory != null && 
!containsBeanDefinition(beanName)) { 
String nameToLookup = originalBeanName(name); 
/递归 到 BeanFactory 中 寻找 
if (args != null) { 


return (T) parentBeanFactory.getBean(nameToLookup, 


args); 
} 
else { 
return parentBeanFactory.getBean(nameToLookup, 
requiredType); 
j 
j 


/如 果 不 是 仅仅 做 类 型 检查 则 是 创建 bean， 这 里 要 进行 记录 
if (!typeCheckOnly) { 


markBeanAsCreated(beanName); 
j 
/将 存储 XML 配置 文件 的 GernericBeanDefinition 转 换 为 
RootBeanDefinition， 如 果 指 
定 BeanName 是 子 Bean 的 话 同时 会 合并 父 类 的 相关 属性 
final RootBeanDefinition mbd = 
getMergedLocalBeanDefinition(beanName); 
checkMergedBeanDefinition(mbd, beanName, args); 
String[] dependsOn = mbd.getDependsOn(); 
/各 存在 依赖 则 需要 递归 实例 化 依赖 的 bean 
if (dependsOn !- null) { 
for (String dependsOnBean : dependsOn) { 
getBean(dependsOnBean); 
/缓存 依赖 调用 


registerDependentBean(dependsOnBean, beanName); 


j 
/实例 化 依赖 的 bean 后 便 可 以 实例 化 mbd 本 身 了 
/singleton 模 式 的 创建 
if (mbd.isSingleton()) { 
sharedInstance = getSingleton(beanName, new 
ObjectFactory<Object>() 1 
public Object getObject() throws BeansException 1 
try 1 
return createBean(beanName, mbd, args); 
j 


catch (BeansException ex) 1 


destroySingleton(beanName); 


throw ex; 


j 
y 
bean = getObjectForBeanInstance(sharedInstance, name, 
beanName, mbd); 
Jelse if (mbd.isPrototype()) { 
//prototype 模 式 的 创建 (new) 
Object prototypeInstance = null; 
try { 
beforePrototypeCreation(beanName); 
prototypeInstance = createBean(beanName, mbd, args); 
j 
finally { 
afterPrototypeCreation(beanName); 
j 
bean = getObjectForBeanInstance(prototypeInstance, name, 
beanName, mbd); 
jelse { 
// 指 定 的 scope 上 实例 化 bean 
String scopeName = mbd.getScope(); 
final Scope scope - this.scopes.get(scopeName); 
if (scope == null) { 
throw new IllegalStateException("No Scope registered for 
scope ” 


+ scopeName + """); 


j 
try { 
Object scopedInstance = scope.get(beanName, new 
ObjectFactory<Object>() 1 
public Object getObject() throws BeansException 1 
beforePrototypeCreation(beanName); 
try { 
return createBean(beanName, mbd, args); 
j 
finally { 


afterPrototypeCreation(beanName); 


j 
y 
bean = getObjectForBeanInstance(scopedInstance, name, 
beanName, mbd); 
j 
catch (IllegalStateException ex) { 
throw new BeanCreationException(beanName, 
thread; "+ 
"Scope " + scopeName + " is not active for the current 
"consider defining a scoped proxy for this bean if you 
intend to refer to it from a singleton", 


ex); 


/检查 需要 的 类 型 是 否 符合 bean 的 实际 类 型 
if (requiredType != null && bean != null && 
!requiredType.isAssignableFrom 
(bean.getClass())) { 
try { 
return get IypeConverter().convertIf Necessary(bean, 
requiredType); 
j 
catch (TypeMismatchException ex) 1 
if (logger.isDebugEnabled()) 1 


TTT 


logger.debug("Failed to convert bean "+ name + "' to 
required type 
"o 
ClassUtils.getQualifiedName(requiredType) + "|", ex); 
} 


throw new BeanNotOfRequiredTypeException(name, 
requiredType, bean. 
getClass()); 


} 
return (T) bean; 
} 
仅 从 代码 量 上 就 能 看 出 来 bean 的 加 载 经 历 了 一 个 相当 复杂 的 过 
程 ， 其 中 涉及 各 种 各 样 的 考虑 。 相 信 读 者 细心 阅读 上 面 的 代码 ， 并 参 
照 部 分 代码 注释 ， 是 可 以 粗略 地 了 解 整个 Spring 加 载 bean 的 过 程 。 对 
于 加 载 过 程 中 所 涉及 的 步骤 大 致 如 下 。 
(1) 转换 对 应 beanNameo 


或 许 很 多 人 不 理解 转换 对 应 beanName 是 什么 意思 ， 传 入 的 参数 
name 不 就 是 beanName 吗 ? 其 实 不 是 ， 这 里 传 入 的 参数 可 能 是 别名 ， 
也 可 能 是 FactoryBean， 所 以 需要 进行 一 系列 的 解析 ， 这 些 解析 内 容 包 
括 如 下 内 容 。 

去 除 FactoryBean 的 修饰 符 ， 也 就 是 如 果 name="&aa"， 那 么 会 首先 
去 除 & 而 使 name="aa"。 

取 指 定 alias 所 表示 的 最 终 beanName， 例 如 别名 A 指 向 名 称 为 B 的 
bean 则 返回 B; 若 别名 A 指 向 别名 B， 别 名 B 又 指向 名 称 为 C 的 bean 则 返 
回 C。 

(2) 尝试 从 缓存 中 加 载 单 例 。 

单 例 在 Spring 的 同一 个 容器 内 只 会 被 创建 一 次 ， 后 续 再 获取 
bean， 就 直接 从 单 例 缓存 中 获取 了 。 当 然 这 里 也 只 是 尝试 加 载 ， 首 先 
尝试 从 缓存 中 加 载 ， 如 果 加 载 不 成 功 则 再 次 尝试 从 singletonFactories 中 
加 载 。 因 为 在 创建 单 例 bean 的 时 候 会 存在 依赖 注入 的 情况 ， 而 在 创建 
依赖 的 时 候 为 了 避免 循环 依赖 ， 在 Spring 中 创建 bean 的 原则 是 不 等 bean 
创建 完成 就 会 将 创建 bean 的 ObjectFactory 提 早 曝光 加 入 到 缓存 中 ， 一 
旦 下 一 个 bean 创 建 时 候 需 要 依赖 上 一 个 bean 则 直接 使 用 ObjectFactory 

(后 面 章 节 会 对 循环 依赖 重点 讲解 ) 。 
(3) bean 的 实例 化 。 

如 果 从 缓存 中 得 到 了 bean 的 原始 状态 ， 则 需要 对 bean 进 行 实例 
化 。 这 里 有 必要 强调 一 下 ， 缓 存 中 记录 的 只 是 最 原始 的 bean 状态 ， 并 
不 一 定 是 我 们 最 终 想 要 的 bean。 举 个 例子 ， 假 如 我 们 需要 对 工厂 bean 
进行 处 理 ， 那 么 这 里 得 到 的 其 实 是 工厂 bean 的 初始 状态 ， 但 是 我 们 真 
正 需要 的 是 工厂 bean 中 定义 的 factory-method 方 法 中 返回 的 bean， 而 
getObjectForBeanInstance 就 是 完成 这 个 工作 的 ， 后 续 会 详细 讲解 。 

(4) 原型 模式 的 依赖 检查 。 


只 有 在 单 例 情况 下 才 会 尝试 解决 循环 依赖 ， 如 果 存 在 A 中 有 B 的 属 
性 ，B 中 有 A 的 属性 ， 那 么 当 依赖 注入 的 时 候 ， 就 会 产生 当 A 还 未 创建 
完 的 时 候 因 为 对 于 B 的 创建 再 次 返回 创建 A， 造 成 循环 依赖 ， 也 就 是 情 
况 : isPrototypeCurrentlyInCreation(beanName) 判 断 true。 

(5) 检测 parentBeanFactory。 

从 代码 上 看 ， 如 果 缓 存 没有 数据 的 话 直接 转 到 父 类 工厂 上 去 加 载 
了 ， 这 是 为 什么 呢 ? 

可 能 读者 忽略 了 一 个 很 重要 的 判断 条 件 : parentBeanFactory != 
null && !containsBean Definition (beanName), parentBeanFactory != 
null。parentBeanFactory 如 果 为 空 ， 则 其 他 一 切 都 是 浮云 ， 这 个 没什么 
说 的 ， 但 是 !containsBeanDefinition(beanName) 就 比较 重要 了 ， 它 是 在 
检测 如 果 当 前 加 载 的 XML 配置 文件 中 不 包含 beanName 所 对 应 的 配置 ， 
就 只 能 到 parentBeanFactory 去 尝试 下 了 ， 然 后 再 去 递归 的 调用 getBean 
万 法 5 

(6) 将 存储 XML 配置 文件 的 GernericBeanDefinition 转 换 为 
RootBeanDefinitiono 

为 从 XML 配置 文件 中 读 取 到 的 Bean 信 息 是 存储 在 
GernericBeanDefinition 中 的 ， 但 是 所 有 的 Bean 后 续 处 理 都 是 针对 于 
RootBeanDefinition 的 ， 所 以 这 里 需要 进行 一 个 转换 ， 转 换 的 同时 如 果 
父 类 bean 不 为 空 的 话 ， 则 会 一 并 合并 父 类 的 属性 。 

(7) 寻找 依赖 。 

为 bean 的 初始 化 过 程 中 很 可 能 会 用 到 某 些 属性 ， 而 某 些 属性 很 
可 能 是 动态 配置 的 ， 并 且 配 置 成 依赖 于 其 他 的 bean， 那 么 这 个 时 候 就 
有 必要 先 加 载 依赖 的 bean， 所 以 ， 在 Spring 的 加 载 顺 寻 中 ， 在 初始 化 
某 一 个 bean 的 时 候 首 先 会 初始 化 这 个 bean 所 对 应 的 依赖 。 

(8) 针对 不 同 的 scope 进 行 bean 的 创建 。 


我 们 都 知道 ， 在 Spring 中 存在 着 不 同 的 scope， 其 中 默认 的 是 
singleton， 但 是 还 有 些 其 他 的 配置 诸如 prototype、request 之 类 的 。 在 这 
个 步骤 中 ，Spring 会 根据 不 同 的 配置 进行 不 同 的 初始 化 策略 。 

(9) 类 型 转换 。 

程序 到 这 里 返回 bean 后 已 经 基本 结束 了 ， 通 常 对 该 方法 的 调用 参 
数 requiredType 是 为 空 的 ， 但 是 可 能 会 存在 这 样 的 情况 ， 返 回 的 bean 
其 实 是 个 String， 但 是 requiredType 却 传 入 Integer 类 型 ， 那 么 这 时 候 
本 步骤 就 会 起 作用 了 ， 它 的 功能 是 将 返回 的 bean 转 换 为 requiredType 所 
指定 的 类 型 。 当 然 ，String 转 换 为 Integer 是 最 简单 的 一 种 转换 ， 在 
Spring 中 提供 了 各 种 各 样 的 转换 器 ， 用 户 也 可 以 自己 扩展 转换 器 来 满 
足 需 求 。 

经 过 上 面 的 步骤 后 bean 的 加 载 就 结束 了 ， 这 个 时 候 就 可 以 返回 我 
们 所 需要 的 bean 了， 图 5-1 直 观 地 反映 了 整个 过 程 。 其 中 最 重要 的 就 是 
步骤 (8) ， 针 对 不 同 的 scope 进 行 bean 的 创建 ， 你 会 看 到 各 种 常用 的 
Spring 特 性 在 这 里 的 实现 。 

在 细 化 分 析 各 个 步骤 提供 的 功能 前 ， 我 们 有 必要 先 了 解 下 
FactoryBean 的 用 法 。 
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图 5-1 bean 的 获取 过 程 


5.1 FactoryBean 的 使 用 


一 般 情 况 下 ，Spring 通 过 反射 机 制 利 用 bean 的 class 属 性 指定 实现 类 
来 实例 化 bean 。 在 某 些 情况 下 ， 实 例 化 bean 过 程 比较 复杂 ， 如 果 按 照 
传统 的 方式 ， 则 需要 在 <bean> 中 提供 大 量 的 配置 信息 ， 配 置 方式 的 灵 
活性 是 受 限 的 ， 这 时 采用 编码 的 方式 可 能 会 得 到 一 个 简单 的 方案 。 
Spring 为 此 提供 了 一 个 org.Springframework.bean.factory.FactoryBean 的 
工厂 类 接口 ， 用 户 可 以 通过 实现 该 接口 定制 实例 化 bean 的 逻辑 。 
FactoryBean 接口 对 于 Spring 框架 来 说 占有 重要 的 地 位 ，Spring 自 
身 就 提供 了 70 多 个 FactoryBean 的 实现 。 它 们 隐藏 了 实例 化 一 些 复 杂 
bean 的 细节 ， 给 上 层 应 用 带 来 了 便利 。 从 Spring 3.0 开 始 ， FactoryBean 
开始 支持 泛 型 ， 即 接口 声明 改 为 FactoryBean<T> 的 形式 : 
package org.Springframework.beans.factory; 
public interface FactoryBean<T> { 
T getObject() throws Exception; 
Class<?> getObjectType(); 
boolean isSingleton(); 
j 
在 该 接口 中 还 定义 了 以 下 3 个 方法 。 
T getObject(): 返回 由 FactoryBean 创 建 的 bean 实 例 ， 如 果 
isSingleton() 返 回 true， 则 该 实例 会 放 到 Spring 容器 中 单 实 例 缓 存 池 
中 。 
boolean isSingleton(): 返回 由 FactoryBean 创 建 的 bean 实例 的 作用 
域 是 singleton prototypes 
Class<T> getObjectType(): 返回 FactoryBean 创 建 的 bean 类 型 。 
当 配 置 文件 中 <bean> 的 class 属 性 配置 的 实现 类 是 FactoryBean 
时 ， 通 过 getBean() 方 法 返回 的 不 是 FactoryBean 本 身 ， 而 是 


FactoryBean#getObject() 方 法 所 返回 的 对 象 ， 相 当 于 
FactoryBean#getObject() 代 理 了 getBean() 方 法 。 例 如 : 如 果 使 用 传统 方 
式 配 置 下 面 Car 的 <bean> 时 ，Car 的 每 个 属性 分 别 对 应 一 个 <property> 
元 素 标 签 。 
public class Car { 
private int maxSpeed ; 
private String brand ; 
private double price ; 
//get/set 方 法 
} 
如 果 用 FactoryBean 的 方式 实现 就 会 灵活 一 些 ， 下 例 通 过 逗号 分 着 
符 的 方式 一 次 性 地 为 Car 的 所 有 属性 指定 配置 值 : 
public class CarFactoryBean implements FactoryBean<Car> { 
private String carInfo ; 
public Car getObject () throws Exception 1 
Car car = new Car () ; 
String [] infos = carInfo .split ( "," ) ; 
car.setBrand ( infos [ 0 ]) ; 
car.setMaxSpeed ( Integer. valueOf ( infos [ 1 ])) ; 
car.setPrice ( Double. valueOf ( infos [ 2 ])) ; 
return Car; 
j 
public Class<Car> getObjectType () 1 
return Car. class ; 
j 
public boolean isSingleton () 1 


return false ; 


j 
public String getCarInfo () 1 
return this . carInfo ; 
J 
// ES238 5 HAPLESS 
public void setCarInfo ( String carInfo ) { 


this . carInfo = carInfo; 


} 

有 了 这 个 CarFactoryBean 后 ， 就 可 以 在 配置 文件 中 使 用 下 面 这 种 
自 定 义 的 配置 方式 配置 Car Bean 了: 

<bean id="car" class-"com.test.factorybean.CarFactory Bean" 
carInfo=" 起 级 跑车 ,400,2000000"/> 

当 调 用 getBean("car") BY, Spring 通过 反射 机 制 发 现 
CarFactoryBean 实现 了 FactoryBean 的 接口 ， 这 时 Spring 容 器 就 调用 接 
口 方 法 CarFactoryBean#getObject() 方 法 返回 。 如 果 希 望 获取 
CarFactoryBean 的 实例 ， 则 需要 在 使 用 getBean(beanName) 方法 时 在 
beanName 前 显示 的 加 上 "&" 前 缀 ， 例 如 getBean("&car'")。 


5.2 bean 


绍 过 FactoryBean 的 用 法 后 ， 我 们 就 可 以 了 解 bean 加 载 的 过 程 
To 前面 已 经 提 到 过 ， 单 例 在 Spring 的 同一 个 容器 内 只 会 被 创建 一 
次 ， 后 续 再 获取 bean 直 接 从 单 例 缓存 中 获取 ， 当 然 这 里 也 只 是 尝试 加 
载 ， 首 先 尝试 从 缓存 中 加 载 ， 然 后 再 次 尝试 尝试 从 singletonFactories 中 
加 载 。 因 为 在 创建 单 例 bean 的 时 候 会 存在 依赖 注入 的 情况 ， 而 在 创建 
依赖 的 时 候 为 了 避免 循环 依赖 ， Spring 创建 bean 的 原则 是 不 等 bean 创 


介 


建 完成 就 会 将 创建 bean 的 ObjectFactory 提 早 曝光 加 入 到 缓存 中 ， 一 
下 一 个 bean 创 建 时 需要 依赖 上 个 bean， 则 直接 使 用 ObjectFactory。 
public Object getSingleton(String beanName) { 
// 参 数 true 设 置 标识 允许 早期 依赖 
return getSingleton(beanName, true); 


} 


protected Object getSingleton(String beanName, boolean 
allowEarlyReference) { 


// 检 查 缓存 中 是 否 存在 实例 
Object singletonObject = this.singletonObjects.get(beanName); 
if (singletonObject == null) { 
/如 果 为 空 ， 则 锁定 全 局 变量 并 进行 处 理 
synchronized (this.singletonObjects) { 
/如 果 此 bean 正 在 加 载 则 不 处 理 
singletonObject = this.earlySingletonObjects.get(beanName); 
if (singletonObject == null && allowEarlyReference) ( 
// 当 某 些 方法 需要 提前 初始 化 的 时 候 则 会 调用 
addSingletonFactory 方法 将 对 应 


的 ObjectFactory 初 始 化 策略 存储 在 singletonFactories 
(beanName); 


ObjectFactory singletonFactory = this.singletonFactories.get 
if (singletonFactory !- null) { 


/调用 预先 设 定 的 getObject 方 法 
singletonObject = singletonFactory.getObject(); 


/记录 在 缓存 中 ，earlySingletonObjects 和 
singletonFactories 互 斥 


this.earlySingletonObjects.put(beanName, 


singletonObject); 
this.singletonFactories.remove(beanName); 
j 
j 
j 

j 

return (singletonObject != NULL OBJECT ? singletonObject : 
null); 

} 


这 个 方法 因为 涉及 循环 依赖 的 检测 ， 以 及 涉及 很 多 变量 的 记录 存 
取 ， 所 以 让 很 多 读者 摸 不 着 头脑 。 这 个 方法 首先 尝试 从 
singletonObjects 里 面 获 取 实 例 ， 如 果 获 取 不 到 再 从 earlySingleton 
Objects 里 面 获 取 ， 如 果 还 获取 不 到 ， 再 尝试 从 singletonFactories 里 面 
获取 beanName 对 应 的 ObjectFactory， 然 后 调用 这 个 ObjectFactory 的 
getObject 来 创建 bean， 并 放 到 earlySingleton Objects 里 面 去 ， 并 且 从 
singletonFacotories 里 面 remove 掉 这 个 ObjectFactory， 而 对 于 后 续 的 所 
有 内 存 操作 都 只 为 了 循环 依赖 检测 时 候 使 用 ， 也 就 是 在 
allowEarlyReference 为 true 的 情况 下 才 会 使 用 。 

这 里 涉及 用 于 存储 bean 的 不 同 的 map， 可 能 让 读者 感到 骨 溃 ， 简 
单 解 释 如 下 。 

singletonObjects: 用 于 保存 BeanName 和 创建 bean 实 例 之 间 的 天 
系 ，bean name --> bean instanceo 

singletonFactories: 用 于 保存 BeanName 和 创建 bean 的 工厂 之 间 的 
KFA, bean name -->ObjectFactoryo 

earlySingletonObjects: 也 是 保存 BeanName 和 创建 bean 实例 之 间 
的 关系 ， 与 singletonObjects 的 不 同 之 处 在 于 ， 当 一 个 单 例 bean 被 放 到 


这 里 面 后 ， 那 么 当 bean 还 在 创建 过 程 中 ， 就 可 以 通过 getBean 方 法 获取 
到 了 ， 其 目的 是 用 来 检测 循环 引用 。 
registeredSingletons: 用 来 保存 当前 所 有 已 注册 的 bean。 


5.3 从 bean 的 实例 中 获取 对 象 


在 getBean 方法 中 ，getObjectForBeanInstance 是 个 高 频率 使 用 的 
方法 ， 无 论 是 从 缓存 中 获得 bean 还 是 根据 不 同 的 scope 策 略 加 载 bean。 
总 之 ， 我 们 得 到 bean 的 实例 后 要 做 的 第 一 步 就 是 调用 这 个 方法 来 检测 
一 下 正确 性 ， 其 实 就 是 用 于 检测 当前 bean 是 否 是 FactoryBean 类 型 的 
bean， 如 果 是 ， 那 么 需要 调用 该 bean 对 应 的 FactoryBean 实 例 中 的 
getObject() 作 为 返回 值 。 

无 论 是 从 缓存 中 获取 到 的 bean 还 是 通过 不 同 的 scope 策 略 加 载 的 
bean 都 只 是 最 原始 的 bean 状 态 ， 并 不 一 定 是 我 们 最 终 想 要 的 bean。 举 
个 例子 ， 假 如 我 们 需要 对 工厂 bean 进 行 处 理 ， 那 么 这 里 得 到 的 其 实 
IJ bean 的 初始 状态 ， 但 是 我 们 真正 需要 的 是 工厂 bean ney 
factory-method 方 法 中 返回 的 bean， 而 getObjectForBeanInstance 方 法 就 
是 完成 这 个 工作 的 。 

protected Object getObjectForBeanInstance( 

Object beanInstance, String name, String beanName, 
RootBeanDefinition mbd) { 

/如 果 指 定 的 name 是 工矿 相关 (以 & 为 前 缀 ) 且 beanInstance 又 不 是 
FactoryBean 类 型 则 验证 不 通过 

if (BeanFactoryUtils.isFactoryDereference(name) && ! 
(beanInstance instanceof 


FactoryBean)) { 


throw new 
BeanIsNotA FactoryException(transformedBeanName(name), beanInstance. 
getClass()); 
j 
/现在 我 们 有 了 个 bean 的 实例 ， 这 个 实例 可 能 会 是 正常 的 bean 或 
者 是 FactoryBean 
/如 果 是 FactoryBean 我 们 使 用 它 创 建 实例 ， 但 是 如 果 用 户 想 要 
直接 获取 工厂 实例 而 不 是 工厂 的 
getObject 方 法 对 应 的 实例 那么 传 入 的 name 应 该 加 入 前 缀 & 
if (!(beanInstance instanceof FactoryBean) || BeanFactoryUtils. 
IsFactory 
Dereference(name)) { 
return beanInstance; 
} 
/加 载 FactoryBean 
Object object = null; 
if (mbd == null) ( 
// 尝 试 从 缓存 中 加 载 bean 
object = getCachedObjectForFactoryBean(beanName); 
} 
if (object == null) { 
// 到 这 里 已 经 明确 知道 beanInstance 一 定 是 FactoryBean 类 型 
FactoryBean<?> factory = (FactoryBean<?>) beanInstance; 
//containsBeanDefinition 检 测 beanDefinitionMap 中 也 就 是 在 所 
有 已 经 加 载 的 类 中 检测 
是 否定 义 beanName 
if (mbd == null && containsBeanDefinition(beanName)) 1 


// 将 存储 XML 配置 文件 的 GernericBeanDefinition 转 换 为 
RootBeanDefinition ， 
如 果 指 定 BeanName 是 子 Bean 的 话 同时 会 合并 父 类 的 相关 属 


性 
mbd = getMergedLocalBeanDefinition(beanName); 
j 
// 是 否 是 用 户 定义 的 而 不 是 应 用 程序 本 身 定义 的 
boolean synthetic = (mbd != null && mbd.isSynthetic()); 
object = getObjectFromFactoryBean(factory, beanName, 
Isynthetic); 


j 
return object; 
j 
从 上 面 的 代码 来 看 ， 其 实 这 个 方法 并 没有 什么 重要 的 信息 ， 大 多 
是 些 辅 助 代码 以 及 一 些 功能 性 的 判断 ， 而 真正 的 核心 代码 却 委托 给 了 
getObjectFromFactoryBean ， 我 们 来 看 看 getObjectForBeanInstance 中 的 
所 做 的 工作 。 
(1) 对 FactoryBean 正 确 性 的 验证 。 
(2) 对 非 FactoryBean 不 做 任何 处 理 。 
(3) 对 bean 进 行 转换 。 
(4) 将 从 Factory 中 解析 bean 的 工作 委托 给 
getObjectFromFactoryBeano 
protected Object getObjectFromFactoryBean(FactoryBean factory, 
String beanName, boolean 
shouldPostProcess) { 
/如 果 是 单 例 模式 
if (factory.isSingleton() && containsSingleton(beanName)) 1 


synchronized (getSingletonMutex()) 1 
Object object 7 this.factoryBeanObjectCache.get(beanName); 
if (object == null) { 
shouldPostProcess); 
object = doGetObjectFromFactory Bean(factory, beanName, 
this.factory BeanObjectCache.put(beanName, (object != null 
? object : 
NULL OBJECT)); 
j 
return (object != NULL. OBJECT ? object : null); 


j 
else { 
return doGetObjectFromFactoryBean(factory, beanName, 
shouldPostProcess); 
j 
j 
很 遗憾 ， 在 这 个 代码 中 我 们 还 是 没有 看 到 想 要 看 到 的 代码 ， 在 这 
个 方法 里 只 做 了 一 件 事情 ， 就 是 返回 的 bean 如 果 是 单 例 的 ， 那 就 必须 
要 保证 全 局 唯一 ， 同 时 ， 也 因为 是 单 例 的 ， 所 以 不 必 重 复 创建 ， 可 以 
使 用 缓存 来 提高 性 能 ， 也 就 是 说 已 经 加 载 过 就 要 记录 下 来 以 便于 下 次 
复 用 ， 否 则 的 话 就 直接 获取 了 。 
在 doGetObjectFromFactoryBean 方 法 中 我 们 终于 看 到 了 我 们 想 要 看 
到 的 方法 ， 也 就 是 object =factory.getObject(), TAY, MIM ACA, 
我 们 的 历程 犹如 剥 洋 抱 一 样 ， 一 层 一 层 的 直到 最 内 部 的 代码 实现 ， 虽 
然 很 简单 。 
private Object doGetObjectFromFactoryBean( 


final FactoryBean factory, final String beanName, final boolean 
shouldPostProcess) 


throws BeanCreationException 1 


Object object; 
try { 
// 需 要 权限 验证 


if (System.getSecurityManager() != null) { 
AccessControlContext acc = getAccessControlContext(); 
try 1 
Object>() 1 
object = AccessController.doPrivileged(new 
PrivilegedExceptionAction< 
public Object run() throws Exception { 
return factory.getObject(); 
} 
}, acc); 
} 
catch (PrivilegedActionException pae) { 
throw pae.getException(); 


} 

else { 
/直接 调用 getObject 方 法 
object = factory.getObject(); 


} 


catch (FactoryBeanNotInitializedException ex) 1 


throw new BeanCurrentlyInCreationException(beanName, 
ex.toString()); 
i 
catch (Throwable ex) 1 
throw new BeanCreationException(beanName, "FactoryBean 
threw exception on 
object creation", ex); 
j 
if (object == null && isSingletonCurrentlyInCreation(beanName)) 


throw new BeanCurrentlyInCreationException( 
beanName, "FactoryBean which is currently in creation returned 
null 
from getObject"); 
lj 
if (object != null && shouldPostProcess) { 
try { 
/调用 ObjectFactory 的 后 处 理 器 
object = postProcessObjectFromFactory Bean(object, 
beanName); 
j 
catch (Throwable ex) 1 
throw new BeanCreationException(beanName, "Post- 
processing of the 
Factory Bean's object failed", ex); 


} 


return object; 
j 
上 面 我 们 已 经 讲述 了 FactoryBean 的 调用 方法 ， 如 果 bean 声 明 为 
FactoryBean 类 型 ， 则 当 提取 bean 时 提取 的 并 不 是 FactoryBean， 而 是 
FactoryBean 中 对 应 的 getObject 方 法 返回 的 bean， 而 
doGetObjectFromFactoryBean 正 是 实现 这 个 功能 的 。 但 是 ， 我 们 看 到 在 
上 面 的 方法 中 除了 调用 object = factory.getObject0 得 到 我 们 想 要 的 结果 
后 并 没有 直接 返回 ， 而 是 接 下 来 又 做 了 些 后 处 理 的 操作 ， 这 个 又 是 做 
什么 用 的 呢 ? 于 是 我 们 跟踪 进入 AbstractAutowireCapableBeanFactory 
类 的 postProcessObjectFromFactoryBean 方 法 : 
AbstractAutowireCapableBeanFactory.java 
protected Object postProcessObjectFromFactory Bean(Object object, 
String beanName) 1 
return applyBeanPostProcessorsA fterInitialization(object, 
beanName); 
j 
public Object applyBeanPostProcessorsA fterInitialization(Object 
existingBean, String beanName) 
throws BeansException 1 
Object result = existingBean; 
for (BeanPostProcessor beanProcessor : getBeanPostProcessors()) 1 
result = beanProcessor.postProcessA fterInitialization(result, 
beanName); 
if (result == null) { 


return result; 


return result; 
} 
对 于 后 处 理 器 的 使 用 我 们 还 未 过 多 接触 ， 后 续 章节 会 使 用 大 量 篇 
幅 介绍 ， 这 里 ， 我 们 只 需 了 解 在 Spring 获 取 bean 的 规则 中 有 这 样 一 
条 : 尽 可 能 保证 所 有 bean 初 始 化 后 都 会 调用 注册 的 BeanPostProcessor 
的 postProcessAfterInitialization 方法 进行 处 理 ， 在 实际 开发 过 程 中 大 可 
以 针对 此 特性 设计 自己 的 业务 逻辑 。 


5.4 获取 单 例 


之 前 我 们 讲解 了 从 缓存 中 获取 单 例 的 过 程 ， 那 么 ， 如 果 缓 人 存 中 不 
存在 已 经 加 载 的 单 例 bean 就 需要 从 头 开 始 bean 的 加 载 过 程 了 ， 而 Spring 
中 使 用 getSingleton 的 重 载 方法 实现 bean 的 加 载 过 程 。 

public Object getSingleton(String beanName, ObjectFactory 
singletonFactory) { 

Assert.notNull(beanName, "beanName' must not be null"); 
/全 局 变量 需要 同步 
synchronized (this.singletonObjects) 1 
/首先 检查 对 应 的 bean 是 否 已 经 加 载 过 ， 因 为 singleton 模 式 其 
实 就 是 复 用 以 创建 的 bean， 所 
以 这 一 步 是 必须 的 
Object singletonObject = this.singletonObjects.get(beanName); 
// 如 果 为 空 才 可 以 进行 singleto 的 bean 的 初始 化 
if (singletonObject == null) { 
if (this.singletonsCurrentlyInDestruction) { 
throw new BeanCreationNotAllowedException(beanName, 


"Singleton bean creation not allowed while the singletons 


of this factory are in destruction " + 
"(Do not request a bean from a BeanFactory in a destroy 
method implementation! )"); 
} 
if (logger.isDebugEnabled()) { 
logger.debug(" Creating shared instance of singleton bean " 
+ beanName + "'"); 
j 
beforeSingletonCreation(beanName); 
boolean recordSuppressedExceptions = 
(this.suppressedExceptions —- null); 
if (recordSuppressedExceptions) 1 
this.suppressedExceptions = new 
LinkedHashSet<Exception>(); 
try { 
/初始 化 bean 
singletonObject = singletonFactory.getObject(); 
j 
catch (BeanCreationException ex) { 
if (recordSuppressedExceptions) 1 
for (Exception suppressedException : 
this.suppressedExceptions) 1 


ex.addRelatedCause(suppressedException); 


} 


throw ex; 


j 
finally { 
if (recordSuppressedExceptions) 1 
this.suppressedExceptions - null; 
j 
afterSingletonCreation(beanName); 
j 
/加 入 缓存 
addSingleton(beanName, singletonObject); 
j 
return (singletonObject != NULL OBJECT ? singletonObject : 
null); 


} 

上 述 代码 中 其 实 是 使 用 了 回调 方法 ， 使 得 程序 可 以 在 单 例 创建 的 
前 后 做 一 些 准备 及 处 理 操 作 ， 而 真正 的 获取 单 例 bean 的 方法 其 实 并 不 
是 在 此 方法 中 实现 的 ， 其 实现 逻辑 是 在 ObjectFactory 类 型 的 实例 
singletonFactory 中 实现 的 。 而 这 些 准 备 及 处 理 操作 包括 如 下 内 容 。 

(1) 检查 缓存 是 否 已 经 加 载 过 。 
(2) 若 没有 加 载 ， 则 记录 beanName 的 正在 加 载 状态 。 
(3) 加 载 单 例 前 记录 加 载 状态 。 

可 能 你 会 觉得 beforeSingletonCreation 方 法 是 个 空 实 现 ， 里 面 没 有 
任何 逻辑 ， 但 其 实 不 是 ， 这 个 函数 中 做 了 一 个 很 重要 的 操作 : 记录 加 
载 状态 ， 也 就 是 通过 this.singletonsCurrentlyIn Creation.add(beanName) 
将 当前 正 要 创建 的 bean 记 录 在 缓存 中 ， 这 样 便 可 以 对 循环 依赖 进行 检 
Mle 


protected void beforeSingletonCreation(String beanName) { 


if (!this.inCreationCheckExclusions.contains(beanName) && 
Ithis.singletons 
CurrentlyInCreation.add(beanName)) 1 


throw new BeanCurrentlyInCreationException(beanName); 


} 
(4) 通过 调用 参数 传 入 的 ObjectFactory 的 个 体 Object 方 法 实例 化 
beano 
(5) 加 载 单 例 后 的 处 理 方 法 调用 。 
同步 骤 (3) 的 记录 加 载 状态 相似 ， 当 bean 加 载 结束 后 需要 移 除 缓 
存 中 对 该 bean 的 正在 加 载 状态 的 记录 。 
protected void afterSingletonCreation(String beanName) { 
if (!this.inCreationCheckExclusions.contains(beanName) && 
Ithis.singletons 
CurrentlyInCreation.remove(beanName)) { 
throw new IllegalStateException(" Singleton ' + beanName + ” 
isn't currently 


in creation"); 


} 
(6) 将 结果 记录 至 缓存 并 删除 加 载 bean 过 程 中 所 记录 的 各 种 辅助 

状态 。 

protected void addSingleton(String beanName, Object 
singletonObject) { 

synchronized (this.singletonObjects) { 
this.singletonObjects.put(beanName, (singletonObject != null ? 

singletonObject : 


NULL OBJECT)); 
this.singletonFactories.remove(beanName); 
this.earlySingletonObjects.remove(beanName); 


this.registeredSingletons.add(beanName); 


} 
(7) 返回 处 理 结果 。 
虽然 我 们 已 经 从 外 部 了 解 了 加 载 bean 的 逻辑 架构 ， 但 现在 我 们 还 
并 没有 开始 对 bean 加 载 功 能 的 探索 ， 之 前 提 到 过 ， bean 的 加 载 逻 辑 其 
实 是 在 传 入 的 ObjectFactory 类 型 的 参数 singletonFactory 中 定义 的 ， 我 
们 反 推 参数 的 获取 ， 得 到 如 下 代码 : 
sharedInstance = getSingleton(beanName, new 
ObjectFactory<Object>() { 
public Object getObject() throws BeansException { 
try { 
return createBean(beanName, mbd, args); 
j 
catch (BeansException ex) 1 
destroySingleton(beanName); 


throw ex; 


} 
y 
ObjectFactory 的 核心 部 分 其 实 只 是 调用 了 createBean 的 方法 ， 所 以 
我 们 还 需要 到 createBean 方 法 中 追寻 真理 。 


5.5 / bean 


我 们 不 可 能 指望 在 一 个 函数 中 完成 一 个 复杂 的 逻辑 ， 而 且 我 们 跟 
踪 了 这 么 多 Spring 代码 ， 经 历 了 这 么 多 国 数 ， 或 多 或 少 也 发 现 了 一 些 
规律 : 一 个 真正 干 活 的 函数 其 实 是 以 do 开头 的 ， 比 如 
doGetObjectFromFactoryBean; 而 给 我 们 错觉 的 水 数 ， 比 如 
getObjectFromFactoryBean， 其 实 只 是 从 全 局 角度 去 做 些 统筹 的 工作 。 
这 个 规则 对 于 createBean 也 不 例外 ， 那 么 让 我 们 看 看 在 createBean 函 数 
中 做 了 哪些 准备 工作 。 

protected Object createBean(final String beanName, final 
RootBeanDefinition mbd, final 

Object[] args) throws BeanCreationException { 

if (logger.isDebugEnabled()) { 
logger.debug(" Creating instance of bean " + beanName + """); 
j 
/锁定 class, 根 据 设 置 的 class 属 性 或 者 根据 className 来 解析 Class 
resolveBeanClass(mbd, beanName); 
// 验 证 及 准备 覆盖 的 方法 
try { 
mbd.prepareMethodOverrides(); 
i 
catch (BeanDefinitionValidationException ex) { 
throw new 
BeanDefinitionStoreException(mbd.getResourceDescription(), 
beanName, "Validation of method overrides failed", ex); 
j 
try { 
// 给 BeanPostProcessors 一 个 机 会 来 返回 代理 来 替代 真正 的 实 
例 


Object bean = resolveBeforeInstantiation(beanName, mbd); 
if (bean != null) 1 


return bean; 


j 
catch (Throwable ex) 1 
throw new 
BeanCreationException(mbd.getResourceDescription(), beanName, 
"BeanPostProcessor before instantiation of bean failed", ex); 
j 
Object beanInstance = doCreateBean(beanName, mbd, args); 
if (logger.isDebugEnabled()) { 
logger.debug(" Finished creating instance of bean "" + beanName 
+0"); 
} 
return beanInstance; 
} 
从 代码 中 我 们 可 以 总 结 出 函数 完成 的 具体 步骤 及 功能 。 
(1) 根据 设置 的 class 属 性 或 者 根据 className 来 解析 Class。 
(2) 对 override 属 性 进行 标记 及 验证 。 
很 多 读者 可 能 会 不 知道 这 个 方法 的 作用 ， 因 为 在 Spring 的 配置 里 
面 根本 就 没有 诸如 override-method 之 类 的 配置 ， 那 么 这 个 方法 到 底 是 
干什么 用 的 呢 ? 
其 实在 Spring 中 确实 没有 override-method 这 样 的 配置 ， 但 是 如 果 
读 过 前 面 的 部 分 ， 可 能 会 有 所 发 现 ， 在 Spring 配置 中 是 存在 lookup- 
method 和 replace-method 的 ， 而 这 两 个 配置 的 加 载 其 实 就 是 将 配置 统一 


存放 在 BeanDefinition 中 的 methodOverrides 属 性 里 ， 而 这 个 函数 的 操作 
其 实 也 就 是 针对 于 这 两 个 配置 的 。 

(3) 应 用 初始 化 前 的 后 处 理 器 ， 解 析 指 定 bean 是 否 存 在 初始 化 前 
的 短路 操作 。 

(4) 创建 bean。 

我 们 首先 查看 下 对 override 属 性 标记 及 验证 的 逻辑 实现 。 


5.5.1 Ovverride 


查看 源码 中 AbstractBeanDefinition 类 的 prepareMethodOverrides 方 
法 : 
public void prepareMethodOverrides() throws 
BeanDefinitionValidationException { 
// Check that lookup methods exists. 
MethodOverrides methodOverrides = getMethodOverrides(); 
if (ImethodOverrides.isEmpty()) 1 
for (MethodOverride mo : methodOverrides.getOverrides()) 1 
prepareMethodOverride(mo); 


j 
protected void prepareMethodOverride(MethodOverride mo) throws 
BeanDefinitionValidationException { 
/获取 对 应 类 中 对 应 方法 名 的 个 数 
int count = ClassUtils.getMethodCountForName(getBeanClass(), 
mo.getMethodName()); 
if (count == 0) { 


throw new BeanDefinitionValidationException( 


"Invalid method override: no method with name " + 
mo.getMethodName() + 
" on class [" + getBeanClassName() + "]"); 
} 
else if (count == 1) { 
/标记 MethodOverride 暂 未 被 覆盖 ， 避 免 参数 类 型 检查 的 开 


mo.setOverloaded(false); 
} 

} 

通过 以 上 两 个 水 数 的 代码 你 能 体会 到 它 所 要 实现 的 功能 吗 ? 之 前 
反复 提 到 过 ， 在 Spring 配置 中 存在 lookup-method 和 replace-method 两 个 
配置 功能 ， 而 这 两 个 配置 的 加 载 其 实 就 是 将 配置 统一 存放 在 
BeanDefinition 中 的 methodOverrides 属 性 里 ， 这 两 个 功能 实现 原理 其 实 
是 在 bean 实 例 化 的 时 候 如 果 检 测 到 存在 methodOverrides 属 性 ， 会 动态 
地 为 当前 bean 生 成 代理 并 使 用 对 应 的 拦截 器 为 bean 做 增强 处 理 ， 相 关 
逻辑 实现 在 bean 的 实例 化 部 分 详细 介绍 。 

但 是 ， 这 里 要 提 到 的 是 ， 对 于 方法 的 匹配 来 讲 ， 如 果 一 个 类 中 和 存 
在 若干 个 重 载 方法 ， 那 么 ， 在 冰 数 调用 及 增强 的 时 候 还 需要 根据 参数 
类 型 进行 匹配 ， 来 最 终 确 认 当 前 调用 的 到 底 是 哪个 水 数 。 但 是 ， 
Spring 将 一 部 分 匹配 工作 在 这 里 完成 了 ， 如 果 当 前 类 中 的 方法 只 有 一 
个 ， 那 么 就 设置 重 载 该 方法 没有 被 重 载 ， 这 样 在 后 续 调 用 的 时 候 便 可 
以 直接 使 用 找到 的 方法 ， 而 不 需要 进行 方法 的 参数 匹配 验证 了 ， 而 且 
还 可 以 提前 对 方法 存在 性 进行 验证 ， 正 可 谓 一 箭 双 有 雕 。 


prr 


5.5.2 ! 


在 真正 调用 doCreate 方 法 创建 bean 的 实例 前 使 用 了 这 样 一 个 方法 
resolveBeforeInstantiation (beanName, mbd) 对 BeanDefinigiton 中 的 属性 
A SUE, SA, 无论 其 中 是 否 有 相应 的 逻辑 实现 我 们 都 可 以 理 
解 ， 因 为 真正 逻辑 实现 前 后 留 有 处 理 函 数 也 是 可 扩展 的 一 种 体现 ， 但 
是 ， 这 并 不 是 最 重要 的 ， 在 函数 中 还 提供 了 一 个 短路 判断 ， 这 才 是 最 
为 关键 的 部 分 。 

if (bean != null) { 

return bean; 

j 

当 经 过 前 置 处 理 后 返回 的 结果 如 果 不 为 空 ， 那 么 会 直接 略 过 后 续 
的 Bean 的 创建 而 直接 返回 结果 。 这 一 特 ERINRAR SIRAM, 但 是 
却 起 着 至 天 重要 的 作用 ， 我 们 熟知 的 AOP 功能 就 是 基于 这 里 的 判断 
的 。 

protected Object resolveBeforeInstantiation(String beanName， 
RootBeanDefinition mbd) { 

Object bean = null; 
/如 果 疝 未 被 解析 
if (!Boolean.FALSE.equals(mbd.beforeInstantiationResolved)) { 
// Make sure bean class is actually resolved at this point. 
if (mbd.hasBeanClass() && !mbd.isSynthetic() && 
hasInstantiationAware 
BeanPostProcessors()) { 
bean = 
applyBeanPostProcessorsBeforeInstantiation(mbd.getBeanClass(), 
beanName); 
if (bean != null) { 


bean = applyBeanPostProcessorsA fterInitialization(bean, 


beanName); 


j 
mbd.beforeInstantiationResolved = (bean !- null); 
j 
return bean; 
j 
此 方法 中 最 吸引 我 们 的 无 疑 是 两 个 方法 
applyBeanPostProcessorsBeforeInstantiation 以 及 
applyBeanPostProcessorsAfterInitialization。 两 个 方法 实现 的 非常 简单 ， 
无 非 是 对 后 处 理 器 中 的 所 有 InstantiationAwareBeanPostProcessor 类 型 的 
后 处 理 器 进行 postProcessBeforeInstantiation 方 法 和 BeanPostProcessor 的 
postProcessAfterInitialization 方 法 的 调用 。 
1. 实例 化 前 的 后 处 理 器 应 用 
bean 的 实例 化 前 调用 ， 也 就 是 将 AbsractBeanDefinition 转 换 为 
BeanWrapper 前 的 处 理 。 给 子 类 一 个 修改 BeanDefinition 的 机 会 ， 也 就 
是 说 当 程 序 经 过 这 个 方法 后 ，bean 可 能 已 经 不 是 我 们 认为 的 bean 了 ， 
de ee a E 是 通过 cglib 生 成 的 ， 
也 可 能 是 通过 其 它 技 术 生 成 的 。 这 在 第 7 章 中 会 详细 介绍 ， 我 们 只 需 
dp adc m s 
protected Object apply BeanPostProcessorsBeforeInstantiation(Class 
beanClass, String beanName) 
throws BeansException { 
for (BeanPostProcessor bp : getBeanPostProcessors()) 1 


if (bp instanceof InstantiationAwareBeanPostProcessor) 1 


InstantiationAwareBeanPostProcessor ibp = (Instantiation 
AwareBean 

PostProcessor) bp; 

Object result = ibp.postProcessBeforeInstantiation(beanClass, 
beanName); 

if (result != null) 1 


return result; 


j 
return null; 
j 
2. 实例 化 后 的 后 处 理 器 应 用 
在 讲解 从 缓存 中 获取 单 例 pean 的 时 候 就 提 到 过 ，Spring 中 的 规则 
是 在 bean 的 初始 化 后 尽 可 能 保证 将 注册 的 后 处 理 器 的 
postProcessAfterInitialization 方 法 应 用 到 该 bean 中 ， 因 为 如 果 返 回 的 
bean 不 为 空 ， 那 么 便 不 会 再 次 经 历 普 通 bean 的 创建 过 程 ， 所 以 只 能 在 
这 里 应 用 后 处 理 器 的 postProcessAfterInitialization 方 法 。 
public Object applyBeanPostProcessorsA fterInitialization(Object 
existingBean, String beanName) 
throws BeansException { 
Object result = existingBean; 
for (BeanPostProcessor beanProcessor : getBeanPostProcessors()) 1 
result = beanProcessor.postProcessA fterInitialization(result, 
beanName); 
if (result == null) ( 


return result; 


} 
return result; 


} 


5.6 az 


实例 化 bean 是 一 个 非常 复杂 的 过 程 ， 而 其 中 最 比较 难以 理解 的 就 
是 对 循环 依赖 的 解决 ， 不 管 之 前 读者 有 没有 对 循环 依赖 方面 的 研究 ， 
这 里 有 必要 先 对 此 知识 点 稍 作 回顾 。 


5.6.1 什么 是 和 
循环 依赖 就 是 循环 引用 ， 就 是 两 个 或 多 个 bean 相互 之 间 的 持 有 对 
方 ， 比 如 CircleA 引用 CircleB ，CircleB 引 用 CircleC ，CircleC 引 用 


CircleA， 则 它们 最 终 反 映 为 一 个 环 。 此 处 不 是 循环 调用 ， 循 环 调用 是 
方法 之 间 的 环 调用 ， 如 图 5-2 所 示 。 
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o testB : TestB (3 TestB 
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图 5-2 循环 依赖 


循环 调用 是 无 法 解决 的 ， 除 非 有 终结 条 件 ， 否 则 就 是 死 循环 ， 最 
终 导 致 内 存 浇 出 错误 。 


Spring 容 器 循环 依赖 包括 构造 器 循环 依赖 和 setter 循 环 依赖 ， 那 
Spring 容器 如 何 解决 循环 依赖 呢 ? 首先 让 我 们 来 定义 循环 引用 类 : 
public class TestA { 
private TestB testB; 
public void a() 1 
testB.b(); 
} 
public TestB getTestB() 1 
return testB; 
} 
public void setTestB(TestB testB) { 
this.testB = testB; 


j 
public class TestB { 
private TestC testC; 
public void b() 1 
testC.c(); 
} 
public TestC getTestC() 1 


return testC; 


} 
public void setTestC(TestC testC) { 
this.testC = testC; 


} 
public class TestC { 
private TestA testA; 
public void c() 1 
testA.a(); 
j 
public TestA getTestA() 1 
return testA; 
j 
public void setTestA(TestA testA) 1 
this.testA = testA; 


} 

在 Spring 中 将 循环 依赖 的 处 理 分 成 了 3 种 情况 。 

1. 构造 器 循环 依赖 

表示 通过 构造 器 注入 构成 的 循环 依赖 ， 此 依赖 是 无 法 解决 的 ， 只 
能 抛 出 BeanCurrentlyIn CreationException 异 常 表示 循环 依赖 。 

如 在 创建 TestA 类 时 ， 构 造 器 需要 TestB 类 ， 那 将 去 创建 TestB， 在 
创建 TestB 类 时 又 发 现 需要 TestC 类 ， 则 又 去 创建 TestC， 最 终 在 创建 
TestC 时 发 现 又 需要 TestA， 从 而 形成 一 个 环 ， 没 办 法 创建 。 

Spring 容 器 将 每 一 个 正在 创建 的 bean 标 识 符 放 在 一 个 “当前 创建 
bean 池 ”中 ，bean 标 识 符 在 创建 过 程 中 将 一 直 保 持 在 这 个 池 中 ， 因 此 如 
果 在 创建 bean 过程 中 发 现 自己 已 经 在 “当前 创建 bean 池 ”里 时 ， 将 抛 出 


BeanCurentlyInCreationException 异 常 表示 循环 依赖 ; 而 对 于 创建 完毕 
的 bean 将 从 “当前 创建 bean 闻 ”中 清除 掉 。 
我 们 通过 一 个 直观 的 测试 用 例 来 进行 分 析 。 
(1) 创建 配置 文件 。 
<bean id="testA" class="com.bean.TestA"> 
<constructor-arg index="0" ref="testB"/> 
</bean> 
<bean id="testB" class="com.bean.TestB"> 
«constructor-arg index="0" ref="testC"/> 
</bean> 
<bean id="testC" class="com.bean.TestC"> 
<constructor-arg index="0" ref="testA"/> 
</bean> 
(2) 创建 测试 用 例 。 
@Test(expected = BeanCurrentlyInCreationException.class) 
public void testCircleByConstructor() throws Throwable 1 
try { 
new ClassPathXmlApplicationContext("test.xml"); 
} catch (Exception e) 1 
/因为 要 在 创建 testC 时 抛 出 ; 
Throwable el = e.getCause().getCause().getCause(); 


throw e1; 


} 

针对 以 上 代码 的 分 析 如 下 。 

Spring 容 器 创建 “testA”bean， 首 先 去 “当前 创建 bean 闻 ”查找 是 否 当 
前 bean 正 在 创建 ， 如 果 没 发 现 ， 则 继续 准备 其 需要 的 构造 器 参数 


“testB”， 并 将 "testA” 标 识 符 放 到 “当前 创建 bean 池 ”。 

Spring 容 器 创建 “testB”bean， 首 先 去 “当前 创建 bean 闻 ”查找 是 否 当 

前 bean 正 在 创建 ， 如 果 没 发 现 ， 则 继续 准备 其 需要 的 构造 器 参数 

“testC”， 并 将 “testB” 标 识 符 放 到 “当前 创建 bean 池 ”。 

Spring 容 器 创建 “testC”bean， 首 先 去 “当前 创建 bean 闻 ”查找 是 否 当 
前 bean 正 在 创建 ， 如 果 没 发 现 ， 则 继续 准备 其 需要 的 构造 器 参数 
“testA”， 并 将 “testC” 标 识 符 放 到 “当前 创建 Bean 闻 ”。 

到 此 为 止 Spring 容 器 要 去 创建 “testA”bean， 发 现 该 bean 标 识 符 在 
“当前 创建 bean 池 ”中 ， 因 为 表示 循环 依赖 ， 抛 出 
BeanCurrentlyInCreationExceptiono 

2 。setter 循 环 依赖 

表示 通过 setter 注 入 方式 构成 的 循环 依赖 。 对 于 setter 注 入 造成 的 依 
赖 是 通过 Spring 容器 提前 暴露 刚 完 成 构造 器 注入 但 未 完成 其 他 步骤 

(如 setter 注 入 ) 的 bean 来 完成 的 ， 而 且 只 能 解决 单 例 作 用 域 的 bean 循 

环 依赖 。 通 过 提前 暴露 一 个 单 例 工厂 方法 ， 从 而 使 其 他 bean 能 引用 到 
该 bean， 如 下 代码 所 示 : 

addSingletonFactory(beanName, new ObjectFactory() 1 

public Object getObject() throws BeansException 1 
return getEarlyBeanReference(beanName, mbd, bean); 
j 
y 
具体 步骤 如 下 。 
(1) Spring 容器 创建 单 例 “testA”bean， 首 先 根 据 无 参 构造 器 创建 

bean， 并 暴露 一 个 “ObjectFactory” 用 于 返回 一 个 提前 暴露 一 个 创建 中 的 
bean， 并 将 “testA” 标 识 符 放 到 “当前 创建 bean 闻 ”， 然 后 进行 setter 注 入 
“testB”o 


(2) Spring 容器 创建 单 例 “testB”bean， 首 先 根据 无 参 构造 器 创建 
bean， 并 暴露 一 个 “ObjectFactory” 用 于 返回 一 个 提前 暴露 一 个 创建 中 的 
bean， 并 将 “testB” 标 识 符 放 到 “当前 创建 bean 闻 ”， 然 后 进行 setter 注 入 
“circle”。 
(3) Spring 容器 创建 单 例 “testC”bean， 首 先 根据 无 参 构造 器 创建 
bean， 并 暴露 一 个 “ObjectFactory” 用 于 返回 一 个 提前 暴露 一 个 创建 中 的 
bean， 并 将 “testC” 标 识 符 放 到 “当前 创建 bean 闻 ”， 然 后 进行 setter 注 入 
“testA”。 进行 注入 “testA” 时 由 于 提前 暴露 了 “ObjectFactory” 工 厂 ， 从 
而 使 用 它 返 回 提前 暴露 一 个 创建 中 的 bean。 
(4) 最 后 在 依赖 注入 “testB” 和 “testA”， 完 成 setter 注 入 。 
3. prototype 范 围 的 依赖 处 理 
对 于 “prototype” 作 用 域 bean，Spring 容 器 无 法 完成 依赖 注入 ， 因 为 
Spring 容器 不 进行 缓存 “prototype” 作 用 域 的 bean， 因 此 无 法 提前 暴露 一 
个 创建 中 的 bean。 示 例如 下 : 
(1) 创建 配置 文件 。 
<bean id="testA" class="com.bean.CircleA" scope="prototype"> 
<property name-"testB" ref="testB"/> 
</bean> 
<bean id="testB" class="com.bean.CircleB" scope="prototype"> 
<property name-"testC" ref="testC"/> 
</bean> 
<bean id="testC" class="com.bean.CircleC" scope="prototype"> 
<property name-"testA" ref="testA"/> 
</bean> 
(2) 创建 测试 用 例 。 
@Test(expected = BeanCurrentlyInCreationException.class) 


public void testCircleBySetterAndPrototype () throws Throwable 1 


try { 
ClassPathXmlApplicationContext ctx = new 
ClassPathXmlA pplicationContext( 
"testPrototype.xml"); 
System.out.printIn(ctx.getBean( test A")); 
} catch (Exception e) 1 
Throwable el = e.getCause().getCause().getCause(); 


throw e1; 


} 

对 于 “singleton” 作 用 域 bpeaan， 可 以 通过 
“setAllowCircularReferences(false) ; ”来 禁用 循环 引用 。 

感谢 互联 网 时 代 ， 让 我 可 以 方便 地 获取 我 想 要 的 各 种 信息 ， 当 初 
我 刚 开 始 学 习 的 时 候 ， 一 直 纠 结 于 这 里 错综复杂 的 逻辑 ， 笠 好 我 看 到 
了 一 篇 文章 解 开 了 我 心中 的 疑惑 。 在 此 ， 感 谢 原 作者 ， 并 将 原文 与 大 
家 分 享 ， 帮 助 大 家 更 好 的 理解 Spring 的 依赖 ， 大 家 可 以 从 
http://www.iflym. com/index.php/code/201208280001.html 来 获取 原文 。 


5.7 bean 


介绍 了 循环 依赖 以 及 Spring 中 的 循环 依赖 的 处 理 方式 后 ， 我 们 继 
续 4.5 小 节 的 内 容 。 当 经 历 过 resolveBeforeInstantiation 方法 后 ， 程 序 有 
两 个 选择 ， 如 果 创 建 了 代理 或 者 说 重 写 了 
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法 并 在 方法 postProcess BeforeInstantiation 中 改变 了 bean， 则 直接 返回 
就 可 以 了 ， 否 则 需要 进行 常规 bean 的 创建 。 而 这 常规 bean 的 创建 就 是 
在 doCreateBean 中 完成 的 。 


protected Object doCreateBean(final String beanName, final 
RootBeanDefinition mbd, final 
Object[] args) { 
// Instantiate the bean. 
BeanWrapper instanceWrapper = null; 
if (mbd.isSingleton()) { 
instanceWrapper = 
this.factoryBeanInstanceCache.remove(beanName); 
} 
if (instanceWrapper == null) { 
/根据 指定 bean 使 用 对 应 的 策略 创建 新 的 实例 , 如: 工厂 方 
法 、 构 造 轴 数 自动 注入 、 简 单 初 始 化 
instanceWrapper = createBeanInstance(beanName, mbd, args); 
j 
final Object bean - (instanceWrapper !- null ? instanceWrapper. 
getWrappedInstance() : null); 
Class beanType = (instanceWrapper != null ? 
instanceWrapper.getWrappedClass() : null); 
// Allow post-processors to modify the merged bean definition. 
synchronized (mbd.postProcessingLock) 1 
if (!mbd.postProcessed) { 
/应 用 MergedBeanDefinitionPostProcessor 
applyMergedBeanDefinitionPostProcessors(mbd, beanType, 
beanName); 


mbd.postProcessed = true; 


/* 
* 是 否 需 要 提早 曝光 : 单 例 & 允 许 循环 依赖 & 当 前 bean 正 在 创建 
中 ， 检 测 循环 依赖 
*/ 
boolean earlySingletonExposure = (mbd.isSingleton() && 
this.allowCircularReferences && 
isSingletonCurrentlyInCreation(beanName)); 
if (earlySingletonExposure) 1 
if (logger.isDebugEnabled()) 1 
logger.debug("Eagerly caching bean " + beanName + 
j 
/为 避免 后 期 循环 依赖 ， 可 以 在 bean 初 始 化 完成 前 将 创建 实例 
的 ObjectFactory 加 入 工厂 
addSingletonFactory(beanName, new ObjectFactory() 1 


to allow for resolving potential circular references"); 


public Object getObject() throws BeansException 1 
/对 bean 再 一 次 依赖 引用 ， 主 要 应 用 
SmartInstantiationAware BeanPost 
Processor, 
/其 中 我 们 熟知 的 AOP 就 是 在 这 里 将 advice 动 态 织 入 bean 
中 ， 各 没有 则 直接 返回 
bean， 不 做 任何 处 理 


return getEarlyBeanReference(beanName, mbd, bean); 


D; 
} 


// Initialize the bean instance. 


Object exposedObject = bean; 
try { 
始 依赖 bean 
/对 bean 进 行 填充 ， 将 各 个 属性 值 注入 ， 其 中 ， 可 能 存在 依赖 
于 其 他 bean 的 属性 ， 则 会 递归 初 
populateBean(beanName, mbd, instanceWrapper); 
if (exposedObject != null) { 
/调用 初始 化 方法 ， 比 如 init-method 
exposedObject = initializeBean(beanName, exposedObject, 
mbd); 


catch (Throwable ex) 1 
if (ex instanceof BeanCreationException && 
beanName.equals(((BeanCreationException) 
ex).getBeanName())) 1 
throw (BeanCreationException) ex; 
j 
else { 
throw new 
BeanCreationException(mbd.getResourceDescription(), beanName, 


"Initialization of bean failed", ex); 


} 
if (earlySingletonExposure) { 
Object earlySingletonReference = getSingleton(beanName, 
false); 


/WearlySingletonReference 只 有 在 检测 到 有 循环 依赖 的 情况 下 才 


if (earlySingletonReference != null) 1 


/如 果 exposedObject 没 有 在 初始 化 方法 中 被 改变 ， 也 就 是 没 


有 被 增强 
if (exposedObject == bean) { 
exposedObject = earlySingletonReference; 
(beanName)) { 
}else if (!this.allowRawlInjectionDespiteWrapping && 
hasDependentBean 


String[] dependentBeans = getDependentBeans(beanName); 
Set<String> actualDependentBeans = new 
LinkedHashSet<String> 
(dependentBeans. length); 
for (String dependentBean : dependentBeans) { 
/检测 依赖 
if 
(!IremoveSingletonIfCreatedForTypeCheckOnly(dependentBean)) 1 
actualDependentBeans.add(dependentBean); 


} 
p 
* 因为 bean 创 建 后 其 所 依赖 的 bean 一 定 是 已 经 创建 的 ， 
* actualDependentBeans 不 为 空 则 表示 当前 bean 创 建 后 其 
依赖 的 bean 却 没有 
没 全 部 创建 完 ， 也 就 是 说 存在 循环 依赖 
*/ 


if (lactualDependentBeans.isEmpty()) { 
throw new BeanCurrentlyInCreationException(beanName, 
"Bean with name " + beanName + "' has been injected 
into other beans [" + 
(actual DependentBeans) + 
String Utils.collectionToCommaDelimitedString 
"] in its raw version as part of a circular reference, 
but has eventually been " + 
use the final version of the " + 
"wrapped. This means that said other beans do not 
"bean. This is often the result of over-eager type 
matching - consider using " + 
flag turned off, for example."); 


LLAI 


} 


getBeanNamesOfType' with the 'allowEagerlnit 


j 
// Register bean as disposable. 
try { 
/根据 scopse 注 册 bean 
registerDisposableBeanIfNecessary(beanName, bean, mbd); 
i 
catch (BeanDefinition ValidationException ex) { 
throw new 
BeanCreationException(mbd.getResourceDescription(), beanName, 


"Invalid destruction signature", ex); 


} 
return exposedObject; 

} 

尽管 日 志 与 异常 的 内 容 非 常 重 要 ， 但 是 在 阅读 源码 的 时 候 似乎 大 
部 分 人 都 会 直接 忽略 掉 。 在 此 不 深入 探讨 日 志 及 异常 的 设计 ， 我 们 看 
看 整个 国 数 的 概要 思路 。 

(1) 如 果 是 单 例 则 需要 首先 清除 缓存 。 

(2) 实例 化 bean， 将 BeanDefinition 转 换 为 BeanWrapper。 

转换 是 一 个 复杂 的 过 程 ， 但 是 我 们 可 以 尝试 概括 大 致 的 功能 ， 如 
下 所 示 。 

如 果 存 在 工厂 方法 则 使 用 工厂 方法 进行 初始 化 。 

一 个 类 有 多 个 构造 水 数 ， 每 个 构造 遂 数 都 有 不 同 的 参数 ， 所 以 需 
要 根据 参数 锁定 构造 水 数 并 进行 初始 化 。 

如 果 既 不 存在 工厂 方法 也 不 存在 带 有 参数 的 构造 遂 数 ， 则 使 用 默 
认 的 构造 水 数 进行 bean 的 实例 化 。 

(3) MergedBeanDefinitionPostProcessor 的 应 用 。 

bean 合 并 后 的 处 理 ，Autowired 注 解 正 是 通过 此 方法 实现 诸如 类 型 
的 预 解析 。 

(4) 依赖 处 理 。 

在 Spring 中 会 有 循环 依赖 的 情况 ， 例 如 ， 当 人 A 中 含有 B 的 属性 ， 而 
B 中 又 含有 A 的 属性 时 就 会 构成 一 个 循环 依赖 ， 此 时 如 果 A 和 B 都 是 单 
例 ， 那 么 在 Spring 中 的 处 理 方式 就 是 当 创 建 B 的 时 候 ， 涉 及 自动 注入 A 
的 步骤 时 ， 并 不 是 直接 去 再 次 创建 A， 而 是 通过 放 入 缓存 中 的 
ObjectFactory 来 创建 实例 ， 这 样 就 解决 了 循环 依赖 的 问题 。 

(5) 属性 填充 。 将 所 有 属性 填充 至 bean 的 实例 中 。 

(6) 循环 依赖 检查 。 


之 前 有 提 到 过 ， 在 Sping 中 解决 循环 依赖 只 对 单 例 有 效 ， 而 对 于 
prototype 的 bean，Spring 没 有 好 的 解决 办 法 ， 唯 一 要 做 的 就 是 抛 出 异 
常 。 在 这 个 步骤 里 面 会 检测 已 经 加 载 的 bean 是 否 已 经 出 现 了 依赖 循 
环 ， 并 判断 是 否 需要 抛 出 异 弟 。 

(7) 注册 DisposableBean。 

如 果 配 置 了 destroy-method， 这 里 需要 注册 以 便于 在 销毁 时 候 调 
用 。 

(8) 完成 创建 并 返回 。 

可 以 看 到 上 面 的 步骤 非常 的 繁琐 ， 每 一 步骤 都 使 用 了 大 量 的 代码 
来 完成 其 功能 ， 最 复杂 也 是 最 难以 理解 的 当 属 循环 依赖 的 处 理 ， 在 真 
正 进入 doCreateBean 前 我 们 有 必要 先 了 解 下 循环 依赖 。 


5.7.1 bean 


当 我 们 了 解 了 循环 依赖 以 后 就 可 以 深入 分 析 创 建 bean 的 每 个 步骤 
了 ， 首 先 我们 从 createBeanInstance 开 始 。 
protected BeanWrapper createBeanInstance(String beanName, 
RootBeanDefinition mbd, Object[] args) 1 
/解析 class 
Class beanClass = resolveBeanClass(mbd, beanName); 
if (beanClass != null && 
!Modifier.isPublic(beanClass.getModifiers()) && !mbd. 
isNonPublicAccessAllowed()) 1 
throw new 
BeanCreationException(mbd.getResourceDescription(), beanName, 
"Bean class isn't public, and non-public access not allowed: " + 


beanClass.getName()); 


/如 果 工 三 方法 不 为 空 则 使 用 工厂 方法 初始 化 策略 
if (mbd.getFactoryMethodName() != null) { 


return instantiateUsingFactoryMethod(beanName, mbd, args); 


} 


// Shortcut when re-creating the same bean... 
boolean resolved = false; 
boolean autowireNecessary = false; 
if (args == null) { 
synchronized (mbd.constructorArgumentLock) { 
/一 个 类 有 多 个 构造 沙 数 ， 每 个 构造 函数 都 有 不 同 的 参 
数 ， 所 以 调用 前 需要 先 根据 参数 锁定 
构造 水 数 或 对 应 的 工厂 方法 
if (mbd.resolvedConstructorOrFactoryMethod !- null) { 


resolved - true; 


autowireNecessary = mbd.constructorArgumentsResolved; 


j 
/如 果 已 经 解析 过 则 使 用 解析 好 的 构造 国 数 方法 不 需要 再 次 锁 
定 
if (resolved) { 
if (autowireNecessary) { 
YNE REX EJ LEAN 
return autowireConstructor(beanName, mbd, null, null); 


} 


else { 


8 FA RATA Fie EBA 


return instantiateBean(beanName, mbd); 


i 
ME TS S ARE OESE 
Constructor[] ctors = 
determineConstructorsFromBeanPostProcessors(beanClass, beanName); 
if (ctors != null || 
mbd.getResolvedAutowireMode() == RootBeanDefinition. 
AUTOWIRE_ 
CONSTRUCTOR || 
mbd.hasConstructorArgumentValues() || 
'ObjectUtils.isEmpty(args)) { 
/构造 国 数 目 动 注 入 
return autowireConstructor(beanName, mbd, ctors, args); 
j 
/使 用 默认 构造 水 效 构造 
return instantiateBean(beanName, mbd); 
} 
虽然 代码 中 实例 化 的 细节 非常 复杂 ， 但 是 在 createBeanIntance 方 法 
中 我 们 还 是 可 以 清晰 地 看 到 实例 化 的 逻辑 的 。 
(1) 如 果 在 RootBeanDefinition 中 存在 factoryMethodName 属 性 ， 
或 者 说 在 配置 文件 中 配置 了 factory-method， 那 么 Spring 会 党 试 使 用 
instantiateUsingFactoryMethod(beanName, mbd, args) 方 法 根据 
RootBeanDefinition 中 的 配置 生成 bean 的 实例 。 
(2) 解析 构造 阅 数 并 进行 构造 水 数 的 实例 化 。 因 为 一 个 bean 对 
应 的 类 中 可 能 会 有 多 个 构造 函数 ， 而 每 个 构造 沙 数 的 参数 不 同 ， 
Spring 在 根据 参数 及 类 型 去 判断 最 终 会 使 用 哪个 构造 函数 进行 实例 


化 。 但 是 ， 判 断 的 过 程 是 个 比较 消耗 性 能 的 步骤 ， 所 以 采用 缓存 机 
制 ， 如 果 已 经 解析 过 则 不 需要 重复 解析 而 是 直接 从 RootBeanDefinition 
中 的 属性 resolvedConstructorOrFactoryMethod 缓 存 的 值 去 取 ， 否 则 需 
再 次 解析 ， 并 将 解析 的 结果 添加 至 RootBeanDefinition 中 的 属性 
resolvedConstructorOrFactoryMethod 中 。 
1. autowireConstructor 
对 于 实例 的 创建 Spring 中 分 成 了 两 种 情况 ， 一 种 是 通用 的 实例 
化 ， 另 一 种 是 带 有 参数 的 实例 化 。 带 有 参数 的 实例 化 过 程 相当 复杂 ， 
因为 存在 着 不 确定 性 ， 所 以 在 判断 对 应 参数 上 做 了 大 量 工作 。 
public BeanWrapper autowireConstructor( 
final String beanName, final RootBeanDefinition mbd, Constructor[] 
chosenCtors, final Object[] explicitArgs) { 
BeanWrapperImpl bw = new BeanWrapperImpl(); 
this.beanFactory.initBeanWrapper(bw); 
Constructor constructorToUse - null; 
ArgumentsHolder argsHolderToUse - null; 
Object[] argsToUse - null; 
/WexplicitArgs 通 过 getBean 方 法 传 入 
/如 果 getBean 方 法 调用 的 时 候 指 定 方法 参数 那么 直接 使 用 
if (explicitArgs != null) { 
argsToUse = explicitArgs; 
jelse { 
/如 果 在 getBean 方 法 时 候 没有 指定 则 尝试 从 配置 文件 中 解析 
Object[] argsToResolve = null; 
/党 试 从 缓存 中 获取 


synchronized (mbd.constructorArgumentLock) { 


constructorToUse = (Constructor) 
mbd.resolvedConstructorOrFactory Method; 
if (constructorToUse != null && 
mbd.constructorArgumentsResolved) 1 
/从 缓存 中 取 
argsToUse = mbd.resolvedConstructorArguments; 
if (args ToUse == null) { 
//BC ES AY 44) 15 BIEN BS ZA 


args ToResolve = mbd.preparedConstructorArguments; 


} 
/如 果 缓 存 中 人 存在 
if (argsToResolve !- null) { 
// 解 析 参 数 类 型 ， 如 给 定 方法 的 构造 水 数 A(int,int) 则 通过 
此 方法 后 就 会 把 配置 中 的 
("1","1") 转 换 为 (1,1) 
/缓存 中 的 值 可 能 是 原始 值 也 肯 能 是 最 终 值 
argsToUse = resolvePreparedArguments(beanName, mbd, bw, 
constructor ToUse, 


argsToResolve); 


j 
/没有 被 缓存 
if (constructorToUse == null) { 
// Need to resolve the constructor. 


boolean autowiring = (chosenCtors != null || 


mbd.getResolvedAutowireMode() == 
RootBeanDefinition.AUTOWIRE . 


CONSTRUCTOR); 
ConstructorArgumentValues resolvedValues - null; 
int minNrOfArgs; 
if (explicitArgs != null) { 
minNrOfArgs = explicitArgs.length; 
jelse { 
// 提 取 配 置 文件 中 的 配置 的 构造 遂 数 参数 
ConstructorArgumentValues cargs = 


mbd.getConstructorArgumentValues(); 
/用 于 承载 解析 后 的 构造 沙 数 参 效 的 值 
resolvedValues = new ConstructorArgumentValues(); 
// 能 解析 到 的 参数 个 数 
minNrOfArgs = resolveConstructorArguments(beanName, 
mbd, bw, cargs, 
resolvedValues); 
j 
// Take specified constructors, if any. 
Constructor[] candidates = chosenCtors; 
if (candidates == null) 1 
Class beanClass = mbd.getBeanClass(); 
try 1 
candidates = (mbd.isNonPublicAccessAllowed() ? 


beanClass.getDeclaredConstructors():beanClass. 
getConstructors()); 


catch (Throwable ex) 1 
throw new 
BeanCreationException(mbd.getResourceDescription(), beanName, 
"Resolution of declared constructors on bean Class [" + 
beanClass.getName() + 
"] from ClassLoader [" * beanClass. getClassLoader() 


+ "] failed", ex); 


j 
HERRERNE KX, pubit ERA BRAE DAE FF. 
3FpublicfA ERA ASAA SS E 
AutowireUtils.sortConstructors(candidates); 
int minTypeDiffWeight = Integer. MAX VALUE; 
Set«Constructor» ambiguousConstructors = null; 
List<Exception> causes = null; 
for (int i = 0; i < candidates.length; i++) { 
Constructor<?> candidate = candidates[i]; 
Class[] paramTypes = candidate.getParameterTypes(); 
if (constructorToUse != null && argsToUse.length > 
paramTypes.length) { 
ISO SR OAK EA iS MNS ISNT 
F SAU AYA E CE TSM 
终止 ,因为 已 经 按照 参数 个 数 降 序 排 列 
break; 
j 
if (paramTypes.length < minNrOfArgs) { 


// 参 数 个 数 不 相 等 


continue; 


ArgumentsHolder argsHolder; 
if (resolvedValues !- null) { 
/有 参数 则 根据 值 构造 对 应 参数 类 型 的 参数 
try { 
String[] paramNames = null; 
if (constructorPropertiesAnnotationAvailable) { 
/注释 上 获取 参数 名 称 
(candidate, paramTypes.length); 
paramNames = ConstructorPropertiesChecker. 
evaluateAnnotation 
j 
if (paramNames == null) { 
/获取 参数 名 称 探索 器 
NameDiscoverer(); 
ParameterNameDiscoverer pnd = this.beanFactory. 
getParameter 
if (pnd != null) { 
/获取 指定 构造 国 数 的 参数 名 称 
paramNames = 
pnd.getParameterNames(candidate ); 
j 
j 
/根据 名 称 和 数据 类 型 创建 参数 持 有 者 


argsHolder = createArgumentArray( 


beanName, mbd, resolvedValues, bw, paramTypes, 
paramNames, 
candidate, autowiring); 
j 
catch (UnsatisfiedDependencyException ex) { 
if (this.beanFactory.logger.isTraceEnabled()) { 
this.beanFactory.logger.trace( 
"Ignoring constructor [" + candidate + "] of 
bean " + beanName + "': " + ex); 
j 
if (i == candidates.length - 1 && constructorToUse == 
null) { 
if (causes != null) { 


for (Exception cause : causes) 1 


this.beanFactory.onSuppressedException(cause); 
} 
} 
throw ex; 
} 
else { 
// Swallow and try next constructor. 
if (causes == null) { 
causes = new LinkedList<Exception>(); 
} 
causes.add(ex); 


continue; 


j 
jelse { 
if (paramTypes.length != explicitArgs.length) 1 
continue; 
j 
INEASA SSA TS 20 
argsHolder = new ArgumentsHolder(explicitArgs); 
j 
I FERA xe A ABE EN MIS ae, DUST [TS ERI 
数 的 参数 为 父子 天 系 
int typeDiffWeight = (mbd.isLenientConstructorResolution() ? 
argsHolder.getTypeDifferenceWeight(paramTypes) : 
argsHolder. 
getAssignabilityWeight(paramTypes)); 
OR CARE ARI dE RI LACM e E (FA iS ER] ER 
if (typeDiffWeight « minTypeDiffWeight) ( 
constructorToUse = candidate; 
argsHolderToUse - argsHolder; 
argsToUse - argsHolder.arguments; 
minTypeDiffWeight = typeDiffWeight; 
ambiguousConstructors - null; 
Jelse if (constructorToUse != null && typeDiffWeight == 
min TypeDiffWeight) 1 
if (ambiguousConstructors == null) 1 
ambiguousConstructors = new 


LinkedHashSet<Constructor>(); 


ambiguousConstructors.add(constructorToUse); 


} 


ambiguousConstructors.add(candidate); 


j 
if (constructorToUse == null) { 
throw new 
BeanCreationException(mbd.getResourceDescription(), beanName, 
"Could not resolve matching constructor " + 
"(hint: specify index/type/name arguments for simple 
parameters to avoid type ambiguities)"); 
yelse if (ambiguousConstructors != null && 
!mbd.isLenientConstructor 
Resolution()) 1 
throw new 
BeanCreationException(mbd.getResourceDescription(), beanName, 
"Ambiguous constructor matches found in bean " + beanName 
pU 
"(hint: specify index/type/name arguments for simple 
parameters to avoid type ambiguities): " + 
ambiguousConstructors); 
} 
if (explicitArgs == null) { 
/将 解析 的 构造 水 效 加 入 缓存 


argsHolderToUse.storeCache(mbd, constructor ToUse); 


try { 
Object beanInstance; 
if (System.getSecurityManager() != null) { 
final Constructor ctorToUse = constructorToUse; 
final Object[] argumentsToUse = argsToUse; 
beanInstance = AccessController.doPrivileged(new 
PrivilegedAction< 
Object>(O) { 
public Object run() { 
return beanFactory.getInstantiationStrategy().instantiate( 
mbd, beanName, beanFactory, ctorToUse, 
arguments TOUse); 
j 
}, beanFactory.getA ccessControlContext()); 
j 
else { 
beanInstance = 
this.beanFactory.getInstantiationStrategy().instantiate( 
mbd, beanName, this.beanFactory, constructor ToUse, 
argsToUse); 
j 
/将 构建 的 实例 加 入 BeanWrapper 中 
bw.setWrappedInstance(beanInstance); 
return bw; 
j 
catch (Throwable ex) 1 


throw new 
BeanCreationException(mbd.getResourceDescription(), beanName, 


"Instantiation of bean failed", ex); 


j 

逻辑 很 复杂 ， 函 数 代码 量 很 大 ， 不 知道 你 是 否 坚持 读 完 了 整个 子 
数 并 理解 了 整个 功能 呢 ? 这 里 要 先 吐 个 槽 ， 笔 者 觉得 这 个 函数 的 写法 
完全 不 符合 Spring 的 一 贯 风 格 ， 如 果 你 一 直 跟 随笔 者 的 分 析 思 路 到 这 
里 ， 相 信 你 或 多 或 少 对 Spring 的 编码 风格 有 所 了 解 ，Spring 的 一 贯 做 法 
是 将 复杂 的 逻辑 分 解 ， 分 成 N 个 小 国 数 的 该 套 ， 每 一 层 都 是 对 下 一 层 
逻辑 的 总 结义 概要 ， 这 样 使 得 每 一 层 的 逻辑 会 变 得 简单 容易 理解 。 在 
上 面 的 函数 中 ， 包 含 着 很 多 的 逻辑 实现 ， 笔 者 觉得 至 少 应 该 将 逻辑 封 
靶 在 不 同 函 数 中 而 使 得 在 autowireConstructor 中 的 远 辑 清晰 明了 。 

我 们 总 览 一 下 整个 函数 ， 其 实现 的 功能 考虑 了 以 下 几 个 方面 。 

(1) 构造 函数 参数 的 确定 。 

根据 explicitArgs 参 数 判断 。 

如 果 传 入 的 参数 explicitArgs 不 为 空 ， 那 边 可 以 直接 确定 参数 ， 因 
为 explicitArgs 人 参数 是 在 调用 Bean 的 时 候 用 户 指定 的 ， 在 BeanFactory 类 
中 存在 这 样 的 方法 : 

Object getBean(String name, Object... args) throws BeansException; 

在 获取 bean 的 时 候 ， 用 户 不 但 可 以 指定 bean 的 名 称 还 可 以 指定 
bean 所 对 应 类 的 构造 阔 数 或 者 工厂 方法 的 方法 参数 ， 主 要 用 于 静态 工 
三 方法 的 调用 ， 而 这 里 是 需要 给 定 完全 匹配 的 参数 的 ， 所 以 ， 便 可 以 
判断 ， 如 果 传 入 参数 explicitArgs 不 为 空 ， 则 可 以 确定 构造 沙 数 参数 就 
REO 


缓存 中 获取 。 


除 此 之 外 ， 确 定 参 数 的 办 法 如 果 之 前 已 经 分 析 过 ， 也 就 是 说 构造 
国 数 参数 已 经 记录 在 缓存 中 ， 那 么 便 可 以 直接 拿 来 使 用 。 而 且 ， 这 里 
要 提 到 的 是 ， 在 缓存 中 缓存 的 可 能 是 参数 的 最 终 类 型 也 可 能 是 参数 的 
初始 类 型 ， 例 如 : 构造 永 数 参数 要 求 的 是 int 类 型 ， 但 是 原始 的 参数 
值 可 能 是 String 类 型 的 *1”， 那 么 即使 在 缓存 中 得 到 了 参数 ， 也 需要 经 
过 类 型 转换 器 的 过 滤 以 确保 参数 类 型 与 对 应 的 构造 图 数 参数 类 型 完全 
对 应 。 

配置 文件 获取 。 

如 果 不 能 根据 传 入 的 参数 explicitArgs 确 定 构 造 当 数 的 参数 也 无 法 
在 缓存 中 得 到 相关 信息 ， 那 么 只 能 开始 新 一 轮 的 分 析 了 。 

分 析 从 获取 配置 文件 中 配置 的 构造 水 数 信息 开始 ， 经 过 之 前 的 分 
析 ， 我 们 知道 ，Spring 中 配置 文件 中 的 信息 经 过 转换 都 会 通过 
BeanDefinition 实 例 承载 ， 也 就 是 参数 mbd 中 包含 ， 那 么 可 以 通过 调用 
mbd.getConstructorArgumentValues(0) 来 获取 配置 的 构造 图 数 信息 。 有 了 
配置 中 的 信息 便 可 以 获取 对 应 的 参数 值 信息 了 ， 获 取 参 数值 的 信息 包 
括 直接 指定 值 ， 如 : 直接 指定 构造 遂 数 中 某 个 值 为 原始 类 型 String 类 
型 ， 或 者 是 一 个 对 其 他 bean 的 引用 ， 而 这 一 处 理 委托 给 
resolveConstructorArguments 方 法 ， 并 返回 能 解析 到 的 参数 的 个 数 。 

(2) ERRAI Eo 

经 过 了 第 一 步 后 已 经 确定 了 构造 函数 的 参数 ， 接 下 来 的 任务 就 是 
根据 构造 沙 数 参数 在 所 有 构造 沙 数 中 锁定 对 应 的 构造 函数 ， 而 匹配 的 
方法 就 是 根据 参数 个 数 匹 配 ， 所 以 在 匹配 之 前 需要 先 对 构造 函数 按照 
public 构 造 函 数 优先 参数 数量 降序 、 非 public 构 造 图 数 参数 数量 降序 。 
这 样 可 以 在 遍历 的 情况 下 迅速 判断 排 在 后 面 的 构造 水 数 参 数 个 数 是 否 
符合 条 件 。 

由 于 在 配置 文件 中 并 不 是 唯一 限制 使 用 参数 位 置 索引 的 方式 去 创 
建 ， 同 样 还 支持 指定 参数 名 称 进 行 设 定 参 数值 的 情况 ， 如 <constructor- 


arg name="aa">， 那 么 这 种 情况 就 需要 首先 确定 构造 为 数 中 的 参数 名 
称 。 
获取 参数 名 称 可 以 有 两 种 方式 ， 一 种 是 通过 注解 的 方式 直接 获 
取 ， 另 一 种 就 是 使 用 Spring 中 提供 的 工具 类 ParameterNameDiscoverer 
来 获取 。 构 造 函 数 、 参 数 名 称 、 参 数 类 型 、 参 数值 都 确定 后 就 可 以 锁 
定 构 造 函 数 以 及 转换 对 应 的 参数 类 型 了 。 
(3) 根据 确定 的 构造 遂 数 转换 对 应 的 参数 类 型 。 
主要 是 使 用 Spring 中 提供 的 类 型 转换 器 或 者 用 户 提 供 的 自 定义 类 
型 转换 器 进行 转换 。 
(4) 构造 函数 不 确定 性 的 验证 。 
当然 ， 有 时 候 即 使 构造 函数 、 参 数 名 称 、 参 数 类 型 、 参 数值 都 确 
定 后 也 不 一 定 会 直接 锁定 构造 国 数 ， 不 同 构造 族 数 的 参数 为 父子 关 
系 ， 所 以 Spring 在 最 后 又 做 了 一 次 验证 。 
(5) 根据 实例 化 策略 以 及 得 到 的 构造 国 数 及 构造 国 数 参数 实例 化 
Bean。 后 面 章节 中 将 进行 讲解 。 
2. instantiateBean 
经 历 了 带 有 参数 的 构造 函数 的 实例 构造 ， 相 信 你 会 非常 轻松 愉快 
地 理解 不 带 参数 的 构造 函数 的 实例 化 过 程 。 
protected BeanWrapper instantiateBean(final String beanName, final 
RootBean 
Definition mbd) { 
try { 
Object beanInstance; 
final BeanFactory parent = this; 
if (System.getSecurityManager() != null) { 
beanInstance = AccessController.doPrivileged(new 


PrivilegedAction 


<Object>() { 
public Object run() { 


return getInstantiationStrategy().instantiate(mbd, 


beanName, 
parent); 
} 
}, getAccessControlContext()); 
} 
else { 
beanInstance = getInstantiationStrategy().instantiate(mbd, 
beanName, 
parent); 
} 
BeanWrapper bw = new BeanWrapperImpl(beanInstance); 
initBeanWrapper(bw); 
return bw; 
} 
catch (Throwable ex) { 
throw new 


BeanCreationException(mbd.getResourceDescription(), beanName, 


"Instantiation of bean failed", ex); 


} 

你 会 发 现 ， 此 方法 并 没有 什么 实质 性 的 逻辑 ， 带 有 参数 的 实例 构 
造 中 ，Spring 把 精力 都 放 在 了 构造 立 数 以 及 参数 的 匹配 上 ， 所 以 如 果 
没有 参数 的 话 那 将 是 非常 简单 的 一 件 事 ， 直 接 调用 实例 化 策略 进行 实 
BEPA T o 


3. 实例 化 策略 
实例 化 过 程 中 反复 提 到 过 实例 化 策略 ， 那 这 又 是 做 什么 用 的 呢 ? 
其 实 ， 经 过 前 面 的 分 析 ， 我 们 已 经 得 到 了 足以 实例 化 的 所 有 相关 信 
息 ， 完 全 可 以 使 用 最 简单 的 反射 方法 直接 反射 来 构造 实例 对 象 ， 但 是 
Spring 却 并 没有 这 么 做 。 
SimpleInstantiationStrategy.java 
public Object instantiate(RootBeanDefinition beanDefinition, String 
beanName, BeanFactory 
owner) 1 
/如 果 有 需要 履 盖 或 者 动态 替换 的 方法 则 当然 需要 使 用 cglib 进 
行动 态 代理 ， 因 为 可 以 在 创建 代理 的 同 
时 将 动态 方法 织 入 类 中 ， 
/但 是 如 果 没 有 需要 动态 改变 得 方法 ， 为 了 方便 直接 反射 就 可 
以 了 
if (beanDefinition.getMethodOverrides().isEmpty()) 1 
Constructor<?> constructor l'oUse; 
synchronized (beanDefinition.constructorArgumentLock) { 
constructorToUse - (Constructor«? 
>)beanDefinition.resolvedConstructor 
OrFactoryMethod; 
if (constructorToUse == null) { 
final Class clazz = beanDefinition.getBeanClass(); 
if (clazz.isInterface()) { 
throw new BeanInstantiationException(clazz, "Specified 
class 


is an interface"); 


try 1 
if (System.getSecurityManager() != null) { 

constructor ToUse = 
AccessController.doPrivileged(new 

PrivilegedExceptionAction<Constructor>() { 

public Constructor run() throws Exception { 
return clazz.getDeclaredConstructor((Class[]) 

null); 


y 
j 
else { 
null); 
constructor ToUse = 
clazz.getDeclaredConstructor((Class[ ]) 
j 
constructor ToUse; 
beanDefinition.resolvedConstructorOrFactory Method = 
j 
catch (Exception ex) 1 
constructor found", ex); 


throw new BeanInstantiationException(clazz, "No default 


} 


return BeanUtils.instantiateClass(constructor ToUse); 
jelse { 


// Must generate CGLIB subclass. 
return instantiateWithMethodInjection(beanDefinition, 
beanName, owner); 
j 
j 
CglibSubclassingInstantiationStrategy.java 
public Object instantiate(Constructor ctor, Object[] args) { 
Enhancer enhancer = new Enhancer(); 
enhancer.setSuperclass(this.beanDefinition.getBeanClass()); 
enhancer.setCallbackFilter(new CallbackFilterImpl()); 
enhancer.setCallbacks(new Callback[] 1 
NoOp.INSTANCE, 
new LookupOverrideMethodInterceptor(), 
new ReplaceOverrideMethodInterceptor() 
y 
return (ctor == null) ? 
enhancer.create() : 
enhancer.create(ctor.getParameterTypes(), args); 
j 
看 了 上 面 两 个 函数 后 似乎 我 们 已 经 感受 到 了 Spring 的 良 苦 用 心 以 
及 为 了 能 更 方便 地 使 用 Spring 而 做 了 大 量 的 工作 。 程 序 中 ， 首 先 判断 
如 果 beanDefinition.getMethodOverrides() 为 空 也 就 是 用 户 没 有 使 用 
replace 或 者 lookup 的 配置 方法 ， 那 么 直接 使 用 反射 的 方式 ， 简 单 快 
捷 ， 但 是 如 果 使 用 了 这 两 个 特性 ， 在 直接 使 用 反射 的 方式 创建 实例 就 
不 受 了 ， 因 为 需要 将 这 两 个 配置 提供 的 功能 切入 进去 ， 所 以 就 必须 要 
使 用 动态 代理 的 方式 将 包含 两 个 特性 所 对 应 的 逻辑 的 拦截 增强 器 设置 


进去 ， 这 样 才 可 以 保证 在 调用 方法 的 时 候 会 被 相应 的 拦截 器 增强 ， 返 
回 值 为 包含 拦截 器 的 代理 实例 。 

对 于 拦截 器 的 处 理 方法 非常 简 单 ， 不 再 详细 介绍 ， 如 果 读 者 有 兴 
趣 ， 可 以 仔细 研读 第 7 章 中 关于 AOP 的 介绍 ， 对 动态 代理 方面 的 知识 会 
有 更 详细 地 介绍 。 


5.7.2 记录 创建 bean 的 ObjectFactory 


在 doCreate 孙 数 中 有 这 样 一 段 代码 : 
boolean earlySingletonExposure = (mbd.isSingleton() && 
this.allowCircularReferences && 
isSingletonCurrentlyInCreation(beanName)); 
if (earlySingletonExposure) { 
if (logger.isDebugEnabled()) { 
logger.debug("Eagerly caching bean " + beanName + 
"' to allow for resolving potential circular references"); 
j 
/为 避免 后 期 循环 依赖 ， 可 以 在 bean 初 始 化 完成 前 将 创建 实例 
的 ObjectFactory 加 入 工厂 
addSingletonFactory(beanName, new ObjectFactory() 1 
public Object getObject() throws BeansException 1 
Processor, 
/对 bean 再 一 次 依赖 引用 ， 主 要 应 用 
SmartInstantiationAware BeanPost 
bean， 不 做 任何 处 理 
// 其 中 我 们 熟知 的 AOP 就 是 在 这 里 将 advice 动 态 织 入 bean 
中 ， 若 没有 则 直接 返回 


return getEarlyBeanReference(beanName, mbd, bean); 


} 
y 
} 

这 段 代码 不 是 很 复杂 ， 但 是 很 多 人 不 是 太 理解 这 段 代 码 的 作用 ， 
而 且 ， 这 段 代码 仅 从 此 函数 中 去 理解 也 很 难 弄 懂 其 中 的 含义 ， 我 们 需 
要 从 全 局 的 角度 去 思考 Spring 的 依赖 解决 办 法 。 

earlySingletonExposure: 从 字面 的 意思 理解 就 是 提早 曝光 的 单 
例 ， 我 们 暂 不 定义 它 的 学 名 叫 什么 ， 我 们 感 兴趣 的 是 有 哪些 条 件 影响 
这 个 值 。 

mbd.isSingleton(): 没有 太 多 可 以 解释 的 ， 此 RootBeanDefinition 代 
表 的 是 否 是 单 例 。 

this.allowCircularReferences: 是 否 允 许 循环 依赖 ， 很 抱歉 ， 并 没 
有 找到 在 配置 文件 中 如 何 配置 ， 但 是 在 
AbstractRefreshableA pplicationContext 中 提供 了 设置 负数 ， 可 以 通过 人 硬 
编码 的 方式 进行 设置 或 者 可 以 通过 自 定 义 命 名 空间 进行 配置 ， 其 中 硬 
编码 的 方式 代码 如 下 。 

ClassPathXmlApplicationContext bf = new 
ClassPathXmlApplicationContext ("aspectTest.xml"); 

bf.setAllowBeanDefinitionOverriding(false); 

isSingletonCurrentlyInCreation(beanName): 该 bean 是 否 在 创建 中 。 
在 Spring 中 ， 会 有 个 专门 的 属性 默认 为 DefaultSingletonBeanRegistry 的 
singletonsCurrentlyInCreation 来 记录 bean 的 加 载 状态 ， 在 bean 开 始 创建 
前 会 将 beanName 记 录 在 属性 中 ， 在 bean 创 建 结束 后 会 将 beanName 从 
属性 中 移 除 。 那 么 我 们 跟随 代码 一 路 走 来 可 是 对 这 个 属性 的 记录 并 没 
有 多 少 印 象 ， 这 个 状态 是 在 哪里 记录 的 呢 ? 不 同 scope 的 记录 位 置 并 不 
一 样 ， 我 们 以 singleton 为 例 ， 在 singleton 下 记录 属性 的 函数 是 在 
DefaultSingletonBeanRegistry 类 的 public Object getSingleton(String 


beanName, ObjectFactory singletonFactory)EKIZX BJ 
beforeSingletonCreation(beanName)All afterSingletonCreation(beanName) 
中 ， 在 这 两 段 国 数 中 分 别 
this.singletonsCurrentlyInCreation.add(beanName) 与 
this.singletonsCurrentlyIn Creation.remove(beanName) 来 进行 状态 的 记录 
与 移 除 。 

经 过 以 上 分 析 我 们 了 解 变量 earlySingletonExposure 是 否 是 单 例 、 
是 否 允 许 循环 依赖 、 是 否 对 应 的 bean 正 在 创建 的 条 件 的 综合 。 当 这 3 个 
条 件 都 满足 时 会 执行 addSingletonFactory 操 作 ， 那 么 加 入 
SingletonFactory 的 作用 是 什么 呢 ? 又 是 在 什么 时 候 调 用 呢 ? 

我 们 还 是 以 最 简单 AB 循 环 依赖 为 例 ， 类 A 中 含有 属性 类 B， 而 类 B 
中 又 会 舍 有 属性 类 A， 那 么 初始 化 beanA 的 过 程 如 图 5-3 所 示 。 


创建 beanA 一 一 | 开始 创建 beam( 记 录 beanNameA) | 


addSingletonFactory | 


populateBean( 填 充 属 性 ) I— —4 开始 创建 bean( 记 录 beanNameB) 


} 


结束 创建 bean( 移 除 beanNamed) | 


; * " 
| addSingletonFactory | 


n 


Eee 


结束 创建 bean( 移 除 beanNameB) | 


图 5-3 处 理 循环 依赖 


图 5-3 中 展示 了 创建 beanA 的 流程 ， 图 中 我 们 看 到 ， 在 创建 A 的 时 
候 首 先 会 记录 类 A 所 对 应 的 beaanName， 并 将 beanA 的 创建 工厂 加 入 缓 
存 中 ， 而 在 对 A 的 属性 填充 也 就 是 调用 populate 方 法 的 时 候 又 会 再 一 次 


的 对 B 进 行 递归 创建 。 同 样 的 ， 因 为 在 B 中 同样 存在 A 属性 ， 因 此 在 实 
例 化 B 的 的 populate 方 法 中 又 会 再 次 地 初始 化 B， 也 就 是 图 形 的 最 后 ， 
调用 getBean(A)。 关 键 是 在 这 里 ， 有 心 的 同学 可 以 去 找 找 这 个 代码 的 
实现 方式 ， 我 们 之 前 已 经 讲 过 ， 在 这 个 函数 中 并 不 是 直接 去 实例 化 
A， 而 是 先 去 检测 缓存 中 是 否 有 已 经 创建 好 的 对 应 的 bean， 或 者 是 否 
已 经 创建 好 的 ObjectFactory， 而 此 时 对 于 A 的 ObjectFactory 我 们 早已 经 
创建 ， 所 以 便 不 会 再 去 向 后 执行 ， 而 是 直接 调用 ObjectFactory 去 创建 
A。 这 里 最 关键 的 是 ObjectFactory 的 实现 。 
addSingletonFactory(beanName, new ObjectFactory() 1 
public Object getObject() throws BeansException 1 
/对 bean 再 一 次 依赖 引用 ， 主 要 应 用 SmartInstantiationAware 
BeanPost 
Processor， 
bean， 不 做 任何 处 理 
/其 中 我 们 熟知 的 AOP 就 是 在 这 里 将 advice 动 态 织 入 bean 中 ， 
若 没 有 则 直接 返回 
return getEarlyBeanReference(beanName, mbd, bean); 
j 
y 
其 中 getEarlyBeanReference 的 代码 如 下 : 
protected Object getEarlyBeanReference(String beanName, 
RootBeanDefinition mbd, Object 
bean) 1 
Object exposedObject = bean; 
if (bean != null && !mbd.isSynthetic() && 
hasInstantiationAwareBean PostProcessors()) 1 


for (BeanPostProcessor bp : getBeanPostProcessors()) { 


if (bp instanceof SmartInstantiationAwareBeanPostProcessor) 


SmartInstantiationAwareBeanPostProcessor ibp = 
(SmartInstantiation 
AwareBeanPostProcessor) bp; 
exposedObject = 
ibp.getEarlyBeanReference(exposedObject, beanName); 
if (exposedObject == null) { 


return exposedObject; 


} 
return exposedObject; 
} 
f£getEarlyBeanReferencePK ZA HARA IK Ze BE RAMIS, RAR 
了 后 处 理 器 的 调用 外 没有 别 的 处 理工 作 ， 根 据 以 上 分 析 ， 基 本 可 以 理 
清 Spring 处 理 循环 依赖 的 解决 办 法 ， 在 B 中 创建 依赖 A 时 通过 
ObjectFactory 提 供 的 实例 化 方法 来 中 断 A 中 的 属性 填充 ， 使 B 中 持 有 的 
A 仅 仅 是 刚刚 初始 化 并 没有 填充 任何 属性 的 A， 而 这 正 初 始 化 A 的 步骤 
还 是 在 最 开始 创建 A 的 时 候 进 行 的 ， 但 是 因为 A 与 B 中 的 A 所 表示 的 属 
性 地 址 是 一 样 的 ， 所 以 在 A 中 创建 好 的 属性 填充 自然 可 以 通过 B 中 的 A 
获取 ， 这 样 融 解决 了 循环 依赖 的 问题 。 


在 了 解 循 环 依赖 的 时 候 ， 我 们 曾经 反复 提 到 了 populateBean 这 个 函 
数 ， 也 多 少 了 解 了 这 个 函数 的 主要 功能 就 是 属性 填充 ， 那 么 究竟 是 如 


何 实现 填充 的 呢 ? 
protected void populateBean(String beanName, 
AbstractBeanDefinition mbd, BeanWrapper bw) { 
Property Values pvs = mbd.getProperty Values(); 
if (bw == null) { 
if (!pvs.isEmpty()) { 
throw new BeanCreationException( 


mbd.getResourceDescription(), beanName, "Cannot apply 


property 
values to null instance"); 
} 
else { 
/没有 可 填充 的 属性 
return; 
} 
} 
/给 InstantiationAwareBeanPostProcessors 最 后 一 次 机 会 在 属性 设 
置 前 来 改变 bean 


/如 : 可 以 用 来 支持 属性 注入 的 类 型 

boolean continueWithPropertyPopulation = true; 

if (!Imbd.isSynthetic() && 

hasInstantiationAwareBeanPostProcessors()) 1 
for (BeanPostProcessor bp : getBeanPostProcessors()) { 
if (bp instanceof InstantiationAwareBeanPostProcessor) 1 

PostProcessor) bp; 
InstantiationAwareBeanPostProcessor ibp = (Instantiation 


AwareBean 


/返回 值 为 是 否 继续 填充 bean 
if 

(‘ibp.postProcessA fterInstantiation(bw.getWrappedInstance(), 
beanName)) { 
continueWithPropertyPopulation = false; 
break; 


} 
/如 果 后 处 理 器 发 出 停止 填充 命令 则 终止 后 续 的 执行 
if (!continueWithPropertyPopulation) { 
return; 
} 
if (mbd.getResolvedAutowireMode() == 
RootBeanDefinition. AUTOWIRE BY NAME || 
mbd.getResolvedAutowireMode() == 
RootBeanDefinition AUTOWIRE_BY_TYPE) { 
MutableProperty Values newPvs = new 
MutableProperty Values(pvs); 
// Add property values based on autowire by name if applicable. 
/根据 名 称 目 动 注入 
if (mbd.getResolvedAutowireMode() == 
RootBeanDefinition.AUTOWIRE BY NAME) { 
autowireByName(beanName, mbd, bw, newPvs); 


} 
// Add property values based on autowire by type if applicable. 


/根据 类 型 目 动 注入 
if (mbd.getResolvedAutowireMode() == 
RootBeanDefinition AUTOWIRE_BY_TYPE) { 


autowireByType(beanName, mbd, bw, newPvs); 


} 
pvs = newPvs; 
} 
/后 处 理 器 已 经 初始 化 


boolean hasInstAwareBpps = 
hasInstantiationAwareBeanPostProcessors(); 
// 需 要 依赖 检查 
boolean needsDepCheck = (mbd.getDependencyCheck() != 
RootBeanDefinition. 
DEPENDENCY CHECK, NONE); 
if (hasInstAwareBpps || needsDepCheck) 1 
PropertyDescriptor[] filteredPds - filterPropertyDescriptors 
ForDependency 
Check(bw); 
if (hasInstAwareBpps) 1 
for (BeanPostProcessor bp : getBeanPostProcessors()) 1 
if (bp instanceof InstantiationAwareBeanPostProcessor) 1 
InstantiationAwareBeanPostProcessor ibp = 
(InstantiationAwareBean 
PostProcessor) bp; 
/对 所 有 需要 依赖 检查 的 属性 进行 后 处 理 
pvs = ibp.postProcessProperty Values(pvs, filteredPds, 
bw.getWrappedInstance(), beanName); 


if (pvs == null) 1 


return; 


if (needsDepCheck) { 
/依赖 检查 ， 对 应 depends-on 属 性 ，3.0 已 经 弃 用 此 属性 
checkDependencies(beanName, mbd, filteredPds, pvs); 


} 

/将 属性 应 用 到 bean 中 

applyProperty Values(beanName, mbd, bw, pvs); 
} 
在 populateBean 国 数 中 提供 了 这 样 的 处 理 流 程 。 

(1) InstantiationAwareBeanPostProcessor 处 理 器 的 
postProcessAfterInstantiation 了 为 数 的 应 用 ， 此 函数 可 以 控制 程序 是 否 继 
续 进 行 属 性 填充 。 

(2) 根据 注入 类 型 (byName/byType) ， 提 取 依 赖 的 bean， 并 统 
一 存 入 PropertyValues 中 。 

(3) 应 用 InstantiationAwareBeanPostProcessor 处 理 器 的 
postProcessPropertyValues 方 法 ， 对 属性 获取 完毕 填充 前 对 属性 的 再 次 
处 理 ， 上 典型 应 用 是 RequiredAnnotationBeanPostProcessor 类 中 对 属性 的 
验证 。 

(4) 将 所 有 PropertyValues 中 的 属性 填充 至 BeanWrapper 中 。 

在 上 面 的 步骤 中 有 几 个 地 方 是 我 们 比较 感 兴趣 的 ， 它 们 分 别 是 依 
赖 注入 (autowire ByName/autowireByType) 以 及 属性 填充 ， 那 么 ， 接 


下 来 进一步 分 析 这 几 个 功能 的 实现 细节 。 
1. autowireByName 
上 文 提 到 根据 注入 类 型 (byName/byType) ， 提 取 依 赖 的 bean， 
并 统一 存 入 PropertyValues 中 ， 那 么 我 们 首先 了 解 下 byName 功 能 是 如 何 
实现 的 。 
protected void autowireByName( 
String beanName, AbstractBeanDefinition mbd, BeanWrapper bw, 
MutableProperty 
Values pvs) 1 
/寻找 bw 中 需要 依赖 注入 的 属性 
String[] propertyNames = unsatisfiedNonSimpleProperties(mbd, 
bw); 
for (String propertyName : propertyNames) 1 
if (containsBean(propertyName)) 1 
/递归 初始 化 相关 的 bean 
Object bean = getBean(propertyName); 
pvs.add(propertyName, bean); 
/注册 依赖 
registerDependentBean(propertyName, beanName); 
if (logger.isDebugEnabled()) 1 
logger.debug(" Added autowiring by name from bean name 
"' + beanName + 


LAAI 


" via property "+ propertyName + "to bean named ” 


+ propertyName + """); 


else { 


if (logger.isTraceEnabled()) { 


logger.trace("Not autowiring property 


"n" v 


+ propertyName + 
nr of 
bean " + beanName + 


" by name: no matching bean found"); 


j 
如 果 读 者 之 前 了 解 了 autowire 的 使 用 方法 ， 相 信和 理解 这 个 函数 的 功 
能 不 会 太 困 难 ， 无 非 是 在 传 入 的 参数 pvs 中 找 出 已 经 加 载 的 bean， 并 递 
归 实 例 化 ， 进 而 加 入 到 pvs 中 。 
2. autowireByType 
autowireByType 5 autowireByName 对 于 我 们 理解 与 使 用 来 说 复杂 
程度 都 很 相似 ， 但 是 其 实现 功能 的 复杂 度 却 完全 不 一 样 。 
protected void autowireBy Type( 
String beanName, AbstractBeanDefinition mbd, BeanWrapper bw, 
MutableProperty Values pvs) 1 
TypeConverter converter = getCustomTypeConverter(); 
if (converter == null) { 
converter = bw; 
j 
Set<String> autowiredBeanNames = new LinkedHashSet<String> 
(4); 
/寻找 bw 中 需要 依赖 注入 的 属性 
String[] propertyNames = unsatisfiedNonSimpleProperties(mbd, 
bw); 


for (String propertyName : propertyNames) { 
try { 
Property Descriptor pd = 
bw.getPropertyDescriptor(propertyName); 
// Don't try autowiring by type for type Object: never makes 
sense, 
// even if it technically is a unsatisfied, non-simple property. 
if (IObject.class.equals(pd.getProperty Type())) 1 
/探测 指定 属性 的 set 方 法 
MethodParameter methodParam = 
BeanUtils.getWriteMethod Parameter(pd); 
boolean eager = !PriorityOrdered.class. isAssignableFrom 
(bw.get 
WrappedClass()); 
DependencyDescriptor desc = new 
AutowireBy TypeDependency Descriptor 
(methodParam, eager); 
/解析 指定 beanName 的 属性 所 匹配 的 值 ， 并 把 解析 到 的 
属性 名 称 存储 在 
autowiredBeanNames 中 ， 当 属性 存在 多 个 封 著 bean 时 
如 : 
//@Autowired private List<A> aList; 将 会 找到 所 有 匹配 A 
类 型 的 bean 并 
将 其 注入 
Object autowiredArgument = resolveDependency(desc, 
beanName, 


autowiredBeanNames, converter); 


if (autowiredArgument !- null) { 


pvs.add(propertyName, autowiredArgument); 


j 
for (String autowiredBeanName : autowiredBeanNames) 1 
/注册 依赖 
registerDependentBean(autowiredBeanName, 
beanName); 
if (logger.isDebugEnabled()) 1 
beanName + " via property "' + 
logger.debug(" Autowiring by type from bean name ”+ 
propertyName + "to bean named "+ 
autowiredBeanName + """); 
} 
} 
autowiredBeanNames.clear(); 
} 
} 


catch (BeansException ex) { 
throw new 
UnsatisfiedDependencyException(mbd.getResourceDescription(), 


beanName, propertyName, ex); 


} 

实现 根据 名 称 自动 匹配 的 第 一 步 就 是 寻找 bw 中 需要 依赖 注入 的 属 
性 ， 同 样 对 于 根据 类 型 自动 匹配 的 实现 来 讲 第 一 步 也 是 寻找 bw 中 需 
依赖 注入 的 属性 ， 然 后 遍历 这 些 属性 并 寻找 类 型 匹配 的 bean， 其 中 最 


复杂 的 就 是 寻找 类 型 匹配 的 bean。 同 时 ，Spring 中 提供 了 对 集合 的 类 
型 注入 的 支持 ， 如 使 用 注解 的 方式 : 

(QAutowired 

private List<Test> tests; 

Spring 将 会 把 所 有 与 Test 匹 配 的 类 型 找 出 来 并 注入 到 tests 属 性 中 ， 
正 是 由 于 这 一 因素 ， 所 以 在 autowireByType 了 国 数 中 ， 新 建 了 局 部 遍历 
autowiredBeanNames， 用 于 存储 所 有 依赖 的 bean， 如 果 只 是 对 非 集合 
类 的 属性 注入 来 说 ， 此 属性 并 无 用 处 。 

对 于 寻找 类 型 匹配 的 逻辑 实现 封装 在 了 resolveDependency 攻 数 
中 。 

DefaultListableBeanFactory.java 

public Object resolveDependency(DependencyDescriptor descriptor, 
String beanName, 

Set<String> autowiredBeanNames, TypeConverter typeConverter) 
throws 


BeansException 1 


descriptor.initParameterNameDiscovery(getParameterNameDiscoverer()); 
if (descriptor.getDependencyType().equals(ObjectFactory.class)) { 
/ObjectFactory 类 注入 的 特殊 处 理 
return new DependencyObjectFactory(descriptor, beanName); 
j 
else if 
(descriptor.getDependencyType().equals(javaxInjectProviderClass)) 1 
//javaxInjectProviderClass 类 注入 的 特殊 处 理 


beanName); 


return new 
DependencyProviderFactory().createDependency Provider (descriptor, 
} 
else { 
// 通 用 处 理 逻 辑 
return doResolveDependency(descriptor, 
descriptor.getDependencyType(), 


beanName, autowiredBeanNames, typeConverter); 


} 

protected Object doResolveDependency(DependencyDescriptor 
descriptor, Class<?> type, 

String beanName, 

Set<String> autowiredBeanNames, TypeConverter typeConverter) 
throws 


BeansException 1 


/* 

* 用 于 文 持 Spring 中 新 增 的 注解 @Value 
2 
Object value = 


getAutowireCandidateResolver().getSuggested Value(descriptor); 
if (value != null) { 
if (value instanceof String) { 
String strVal = resolveEmbeddedValue((String) value); 
BeanDefinition bd = (beanName !- null && 
containsBean(beanName) ? 


getMergedBeanDefinition(beanName) : null); 


value = evaluateBeanDefinitionString(strVal, bd); 
j 
TypeConverter converter = (typeConverter != null ? 
typeConverter : 
get TypeConverter()); 
return converter.convertIf Necessary(value, type); 
j 
/如 果 解 析 器 没有 成 功 解析 ， 则 需要 考虑 各 种 情况 
/属性 是 数组 类 型 
if (type.isArray()) { 
Class<?> componentType = type.getComponentType(); 
/根据 属性 类 型 找到 beanFacotry 中 所 有 类 型 的 匹配 bean， 
/返回 值 的 构成 为 : key= 匹 配 的 beanName,value=beanName 
对 应 的 实例 化 后 的 bean( 通 过 
getBean(beanName)3&[g]) 
Map<String, Object» matchingBeans = 
findAutowireCandidates(beanName, 
componentType, descriptor); 
if (matchingBeans.isEmpty()) { 
/如 果 autowire 的 require 属 性 为 true 而 找到 的 匹配 项 却 为 空 则 
HEBES ERE TÉ 
if (descriptor.isRequired()) 1 
raiseNoSuchBeanDefinitionException(componentType, 
"array of " + 
componentType.getName(), descriptor); 
j 


return null; 


j 
if (autowiredBeanNames !- null) { 
autowiredBeanNames.addAll(matchingBeans.keySet()); 
j 
TypeConverter converter = (typeConverter != null ? 
typeConverter : 
get TypeConverter()); 
/通过 转换 器 将 bean 的 值 转换 为 对 应 的 type 类 型 
return converter.convertIf Necessary(matchingBeans.values(), 
type); 
i 
/属性 是 Collection 类 型 
else if (Collection.class.isAssignableFrom(type) && 
type.isInterface()) { 
Class<?> elementType = descriptor.getCollectionType(); 
if (elementType == null) { 
if (descriptor.isRequired()) { 
throw new FatalBeanException("No element type declared 
for 
collection [" + type.getName() + "]"); 
j 


return null; 


Map<String, Object> matchingBeans = 
findAutowireCandidates(beanName， 
elementType, descriptor); 


if (matchingBeans.isEmpty()) { 


if (descriptor.isRequired()) 1 
raiseNoSuchBeanDefinitionException(elementType, 
"collection of " 
+ elementType.getName(), descriptor); 
} 
return null; 
} 
if (autowiredBeanNames != null) { 
autowiredBeanNames.addAll(matchingBeans.keySet()); 
j 


TypeConverter converter = (typeConverter != null ? 


typeConverter : 
getTypeConverter()); 
return converter.convertIfNecessary(matchingBeans.values(), 
type); 
j 
/属性 是 Map 类 型 
else if (Map.class.isAssignableFrom(type) && type.isInterface()) 
{ 


Class<?> keyType = descriptor.getMapKeyType(); 
if (keyType == null || 
IString.class.isAssignableFrom(key Type)) 1 
if (descriptor.isRequired()) 1 
throw new FatalBeanException("Key type [" + keyType + 
"] of map 
[" + type.getName() + 


"| must be assignable to [java.lang.String |"); 


j 
return null; 
j 
Class<?> valueType = descriptor.getMap ValueType(); 
if (valueType == null) { 
if (descriptor.isRequired()) { 
throw new FatalBeanException("No value type declared 
for map [" 
+ type.getName() + "]"); 
} 
return null; 
} 
Map<String, Object> matchingBeans = 
findAutowireCandidates(beanName, 
valueType, descriptor); 
if (matchingBeans.isEmpty()) { 
if (descriptor.isRequired()) { 
raiseNoSuchBeanDefinitionException(valueType, "map 
with value 
type " + valueType.getName(), descriptor); 
} 
return null; 
} 
if (autowiredBeanNames != null) { 
autowiredBeanNames.addAll(matchingBeans.keySet()); 
j 


return matchingBeans; 


jelse { 
Map<String, Object> matchingBeans = 
findAutowireCandidates(beanName, type, 
descriptor); 
if (matchingBeans.isEmpty()) { 
if (descriptor.isRequired()) { 
raiseNoSuchBeanDefinitionException(type, "", 
descriptor); 
j 
return null; 
j 
if (matchingBeans.size() > 1) 1 
String primaryBeanName = 
determinePrimary Candidate(matchingBeans, 
descriptor); 
if (primaryBeanName == null) { 
matching bean but found " + 
throw new NoSuchBeanDefinitionException(type, 
"expected single 
matchingBeans.size() + ": " + matchingBeans.keySet()); 
} 
if (autowiredBeanNames != null) { 
autowiredBeanNames.add(primaryBeanName); 
} 
return matchingBeans.get(primaryBeanName); 
} 
/已 经 可 以 确定 只 有 一 个 匹配 项 


next(); 


Map.Entry<String, Object» entry = matchingBeans.entrySet(). 


iterator(). 
if (autowiredBeanNames !- null) { 
autowiredBeanNames.add(entry.getKey()); 
} 
return entry.get Value(); 
} 


寻找 类 型 的 匹配 执行 顺序 时 ， 首 先 尝 试 使 用 解析 器 进行 解析 ， 如 
果 解 析 器 没有 成 功 解析 ， 那 么 可 能 是 使 用 默认 的 解析 器 没有 做 任何 处 
理 ， 或 者 是 使 用 了 自 定义 的 解析 器 ， 但 是 对 于 集合 等 类 型 来 说 并 不 在 
解析 汇 围 之 内 ， 所 以 再 次 对 不 同类 型 进行 不 同情 况 的 处 理 ， 虽 说 对 于 
不 同类 型 处 理 方式 不 一 致 ， 但 是 大 致 的 思路 还 是 很 相似 的 ， 所 以 函数 
中 只 对 数组 类 型 进行 了 详细 地 注释 。 
3. applyPropertyValues 
程序 运行 到 这 里 ， 已 经 完成 了 对 所 有 注入 属性 的 获取 ， 但 是 获取 
的 属性 是 以 PropertyValues 形 式 存 在 的 ， 还 并 没有 应 用 到 已 经 实例 化 的 
bean 中 ， 这 一 工作 是 在 applyPropertyValues 中 。 
protected void applyProperty Values(String beanName, BeanDefinition 
mbd, BeanWrapper bw, 
Property Values pvs) 1 
if (pvs == null || pvs.isEmpty()) { 
return; 
j 
MutableProperty Values mpvs - null; 


List«Property Value» original; 


if (System.getSecurityManager()!- null) { 
if (bw instanceof BeanWrapperImpl) { 
((BeanWrapperImpl) 
bw).setSecurityContext(getAccessControlContext()); 
j 
j 
if (pvs instanceof MutableProperty Values) { 
mpvs = (MutableProperty Values) pvs; 
/如 果 mpvs 中 的 值 已 经 被 转换 为 对 应 的 类 型 那么 可 以 直接 设 
置 到 beanwapper 中 
if (mpvs.isConverted()) 1 
// Shortcut: use the pre-converted values as-is. 
try 1 
bw.setProperty Values(mpvs); 
return; 
j 
catch (BeansException ex) 1 
throw new BeanCreationException( 
mbd.getResourceDescription(), beanName, "Error setting 


property values", ex); 


j 
original = mpvs.getProperty ValueL ist(); 
jelse 1 
/如 果 pvs 并 不 是 使 用 MutablePropertyValues 封 装 的 类 型 ， 那 么 
直接 使 用 原始 的 属性 获取 方法 
original = Arrays.asList(pvs.getProperty Values()); 


j 
TypeConverter converter = getCustomTypeConverter(); 
if (converter == null) { 
converter = bw; 
j 
/获取 对 应 的 解析 器 
BeanDefinitionValueResolver valueResolver = new 
BeanDefinition ValueResolver(this, 
beanName, mbd, converter); 
// Create a deep copy, resolving any references for values. 
List«Property Value» deepCopy = new ArrayList«Property Value? 
(original.size()); 
boolean resolveNecessary - false; 
/遍历 属性 ， 将 属性 转换 为 对 应 类 的 对 应 属性 的 类 型 
for (PropertyValue pv : original) { 
if (pv.isConverted()) { 
deepCopy.add(pv); 
jelse 1 
String propertyName - pv.getName(); 
Object originalValue = pv.getValue(); 
Object resolvedValue = 
valueResolver.resolveValueIfNecessary(pv, 
original Value); 
Object convertedValue = resolvedValue; 
boolean convertible = bw.isWritableProperty(propertyName) 
&& 
!PropertyAccessorUtils.isNestedOrIndexedProperty 


(propertyName); 
if (convertible) { 
bw, converter); 
convertedValue = convertForProperty(resolvedValue, 
propertyName, 
j 
if (resolvedValue == originalValue) { 
if (convertible) { 
pv.setConvertedValue(converted Value); 
j 
deepCopy.add(pv); 
j 
else if (convertible && originalValue instanceof 
TypedStringValue && 
!((TypedString Value) originalValue).isDynamic() && 
(convertedValue))) 1 
!(convertedValue instanceof Collection || 
ObjectUtils.isArray 
pv.setConvertedValue(converted Value); 
deepCopy.add(pv); 
j 
else { 
resolveNecessary = true; 


deepCopy.add(new Property Value(pv, convertedValue)); 


if (mpvs != null && !resolveNecessary) 1 
mpvs.setConverted(); 
} 
try { 
bw.setProperty Values(new MutableProperty Values(deepCopy)); 
i 
catch (BeansException ex) { 
throw new BeanCreationException( 
values", ex); 
mbd.getResourceDescription(), beanName, "Error setting 
property 
J 
j 


5.7.4 bean 


大 家 应 该 记得 在 bean 配 置 时 bean 中 有 一 个 init-method 的 属性 ， 这 个 
属性 的 作用 是 在 bean 实 例 化 前 调用 init-method 指 定 的 方法 来 根据 用 户 
业务 进行 相应 的 实例 化 。 我 们 现在 就 已 经 进入 这 个 方法 了 ， 首 先 看 一 
下 这 个 方法 的 执行 位 置 ，Spring 中 程序 已 经 执行 过 bean 的 实例 化 ， 并 
且 进 行 了 属性 的 填充 ， 而 就 在 这 时 将 会 调用 用 尸 设 定 的 初始 化 方法 。 

protected Object initializeBean(final String beanName, final Object 
bean, RootBean 

Definition mbd) { 

if (System.getSecurityManager() != null) { 


AccessController.doPrivileged(new PrivilegedAction<Object>() 


public Object run() { 


invokeAwareMethods(beanName, bean); 
return null; 
j 

}, getAccessControlContext()); 
else { 

/对 特殊 的 bean 处 理 :Aware、BeanClassLoaderAware、 

BeanFactoryAware 

invokeAwareMethods(beanName, bean); 
j 
Object wrappedBean - bean; 
if (mbd == null || !mbd.isSynthetic()) { 

// 应 用 后 处 理 器 

wrappedBean = 

applyBeanPostProcessorsBeforeInitialization(wrappedBean， 

beanName); 
j 
try { 

// 激 活用 户 自 定义 的 init 方 法 

invokeInitMethods(beanName, wrappedBean, mbd); 
j 
catch (Throwable ex) 1 

throw new BeanCreationException( 

(mbd != null ? mbd.getResourceDescription() : null), 

beanName, "Invocation of init method failed", ex); 
j 
if (mbd == null || !mbd.isSynthetic()) { 


/后 处 理 器 应 用 
wrappedBean = 
applyBeanPostProcessorsAfterInitialization(wrappedBean, 
beanName); 
j 
return wrappedBean; 
j 
虽然 说 此 函数 的 主要 目的 是 进行 客户 设 定 的 初始 化 方法 的 调用 ， 
但 是 除 此 之 外 还 有 些 其 他 必要 的 工作 。 
1. 激活 Aware 方 法 
在 分 析 其 原理 之 前 ， 我 们 先 了 解 一 下 Aware 的 使 用 。Spring 中 提供 
一 些 Aware 相 天 接口 ， 比 如 BeanFactoryAware、 
ApplicationContextAware, ResourceLoaderAware, ServletContextAware 
等 ， 实 现 这 些 Aware 接口 的 bean 在 被 初始 之 后 ， 可 以 取得 一 些 相 对 应 
的 资源 ， 例 如 实现 BeanFactoryAware 的 bean 在 初始 后 ， Spring 容器 将 
会 注入 BeanFactory 的 实例 ， 而 实现 ApplicationContextAware 的 bean， 
在 bean 被 初始 后 ， 将 会 被 注入 ApplicationContext 的 实例 等 。 我 们 首先 
通过 示例 方法 来 了 解 一 下 Aware 的 使 用 。 
(1) 定义 普通 bean。 
public class Hello 1 
public void say() 1 
System.out.printIn("hello"); 


j 
(2) 定义 BeanFactoryAware 类 型 的 bean。 
public class Test implements BeanFactoryAware { 


private BeanFactory beanFactory; 


/ 声明 bean 的 时 候 Spring 会 自动 注入 BeanFactory 
@Override 
public void setBeanFactory(BeanFactory beanFactory) throws 
BeansException { 
this.beanFactory = beanFactory; 
} 
public void testAware() { 
/通过 hello 这 个 bean id 从 beanFactory 获 取 实 例 
Hello hello = (Hello) beanFactory.getBean("hello"); 
hello.say(); 


} 
(3) 使 用 main 方 法 测试 。 
public static void main(String[] s) 1 
ApplicationContext ctx = new 
ClassPathXmlApplicationContext("applicationContext.xml"); 
Test test = (Test) ctx.getBean("test"); 


test.testAware(); 


} 
运行 测试 类 ， 控 制 合 输出 : 
hello 


按照 上 面 的 方法 我 们 可 以 获取 到 Spring 中 BeanFactory， 并 且 可 以 
根据 BeanFactory 获 取 所 有 bean， 以 及 进行 相关 设置 。 当 然 还 有 其 他 
Aware 的 使 用 方法 都 大 同 小 异 ， 看 一 下 Spring 的 实现 方式 ， 相 信 读 者 
便 会 使 用 了 。 

private void invokeAwareMethods(final String beanName, final Object 


bean) 1 


if (bean instanceof Aware) 1 
if (bean instanceof BeanNameAware) { 
((BeanName Aware) bean).setBeanName(beanName); 
} 
if (bean instanceof BeanClassLoaderAware) { 
((BeanClassLoaderAware) 
bean).setBeanClassLoader(getBeanClassLoader()); 
} 
if (bean instanceof BeanFactoryAware) { 
Factory.this); 
((BeanFactory Aware) bean).setBeanFactory(AbstractAutowire 
CapableBean 
} 


} 

代码 简单 得 已 经 没有 什么 好 说 的 了 。 读 者 可 以 自己 尝试 使 用 别 的 
Aware， 都 比较 简单 。 

2. 处 理 器 的 应 用 

BeanPostProcessor 相 信 大 家 都 不 卫生 ， 这 是 Spring 中 开放 式 架 构 中 
一 个 必 不 可 少 的 亮点 ， 给 用 户 充 足 的 权限 去 更 改 或 者 扩展 Spring, M 
除了 BeanPostProcessor 外 还 有 很 多 其 他 的 PostProcessor， 当 然 大 部 分 
都 是 以 此 为 基础 ， 继 承 自 BeanPostProcessor。 BeanPostProcessor 的 使 
用 位 置 就 是 这 里 ， 在 调用 客户 自 定义 初始 化 方法 前 以 及 调用 自 定义 初 
始 化 方法 后 分 别 会 调用 BeanPostProcessor 的 
postProcessBeforeInitialization 和 postProcessAfterInitialization 方 法 ， 使 用 
户 可 以 根据 自己 的 业务 需求 进行 响应 的 处 理 。 


public Object applyBeanPostProcessorsBeforelnitialization(Object 
existingBean, String 
beanName) 
throws BeansException { 
Object result = existingBean; 
for (BeanPostProcessor beanProcessor : getBeanPostProcessors()) 1 
result = beanProcessor.postProcessBeforelnitialization(result, 
beanName); 
if (result == null) ( 


return result; 


} 
return result; 
} 
public Object applyBeanPostProcessorsA fterInitialization(Object 
existingBean, String 
beanName) 
throws BeansException { 
Object result = existingBean; 
for (BeanPostProcessor beanProcessor : getBeanPostProcessors()) { 
result = beanProcessor.postProcessA fterInitialization(result, 
beanName); 
if (result == null) { 


return result; 


} 


return result; 


j 
3. 激活 自 定 义 的 init 方 法 
客户 定制 的 初始 化 方法 除了 我 们 熟知 的 使 用 配置 init-method 外 ， 
还 有 使 自 定义 的 bean 实 现 InitializingBean 接 口 ， 并 在 afterPropertiesSet 中 
实现 上 自己 的 初始 化 业务 逻辑 。 
init-method 与 afterPropertiesSet 都 是 在 初始 化 bean 时 执行 ， 执 行 顺 
序 是 afterPropertiesSet 先 执行 ， 而 init-method 后 执行 。 
在 invokeInitMethods 方 法 中 就 实现 了 这 两 个 步骤 的 初始 化 方法 调 
用 。 
protected void invokeInitMethods(String beanName, final Object 
bean, RootBeanDefinition mbd) 
throws Throwable 1 
/首先 会 检查 是 否 是 mnitializingBean， 如 果 是 的 话 需要 调用 
afterPropertiesSet 方 法 
boolean isInitializingBean = (bean instanceof InitializingBean); 
if (isInitializingBean && (mbd == null || !mbd.isExternally 
ManagedInitMethod 
("afterPropertiesSet"))) { 
if (logger.isDebugEnabled()) { 
logger.debug(" Invoking afterPropertiesSet() on bean with 
name ”十 
beanName + """); 
} 
if (System.getSecurityManager() != null) { 
try { 
<Object>() { 


AccessController.doPrivileged(new 
PrivilegedExceptionAction 
public Object run() throws Exception 1 
((InitializingBean) bean).afterPropertiesSet(); 
return null; 
j 
}, getAccessControlContext()); 
j 
catch (PrivilegedActionException pae) 1 
throw pae.getException(); 
j 
jelse 1 
/属性 初始 化 后 的 处 理 


((InitializingBean) bean).afterPropertiesSet(); 


j 

if (mbd != null) 1 
String initMethodName = mbd.getInitMethodName(); 
if (initMethodName != null && !(isInitializingBean && 

"afterPropertiesSet". 
equals(initMethodName)) && 
Imbd.isExternallyManagedInitMethod(initMethodName)) 1 

/调用 自 定 义 初 始 化 方法 


invokeCustomInitMethod(beanName, bean, mbd); 


5.7.5 注册 DisposableBean 


Spring 中 不 但 提供 了 对 于 初始 化 方法 的 扩展 入 口 ， 同 样 也 提供 了 
销毁 方法 的 扩展 入 口 ， 对 于 销毁 方法 的 扩展 ， 除 了 我 们 熟知 的 配置 属 
性 destroy-method 方 法 外 ， 用 户 还 可 以 注册 后 处 理 器 
DestructionAwareBeanPostProcessor 来 统一 处 理 bean 的 销毁 方法 ， 代 码 
如 下 : 

protected void registerDisposableBeanIfNecessary(String beanName, 
Object bean, 

RootBeanDefinition mbd) { 

AccessControlContext acc = (System.getSecurityManager() != null 
? getAccess 
ControlContext() : null); 
if (!Imbd.isPrototype() && requiresDestruction(bean, mbd)) 1 
if (mbd.isSingleton()) { 
f* 
* 单 例 模式 下 注册 需要 销毁 的 bean， 此 方法 中 会 处 理 实 
现 DisposableBean 的 bean, 
* 并 且 对 所 有 的 bean 使 用 
DestructionAwareBeanPostProcessors 处 理 
* DisposableBean Destruction AwareBeanPostProcessors, 
gi 
registerDisposableBean(beanName, 
new DisposableBeanAdapter(bean, beanName, mbd, 
getBeanPost 
Processors(), acc)); 
jelse 1 


/* 
* 自 定义 scope 的 处 理 
gi 
Scope scope = this.scopes.get(mbd.getScope()); 
if (scope == null) { 
throw new IllegalStateException("No Scope registered for 
scope ” 
+ mbd.getScope() + """); 
} 
scope.registerDestructionCallback(beanName, 
new DisposableBeanAdapter(bean, beanName, mbd, 
getBeanPost 


Processors(), acc)); 


第 6 章 _ 容器 的 功能 扩展 


经 过 前 面 几 章 的 分 析 ， 相 信 大 家 已 经 对 Spring 中 的 容器 功能 有 了 
简单 的 了 解 ， 在 前 面 的 章节 中 我 们 一 直 以 BeanFacotry 接 口 以 及 它 的 默 
认 实 现 类 XmlBeanFactory 为 例 进行 分 析 ， 但 是 ， Spring 中 还 提供 了 另 
一 个 接口 ApplicationContext， 用 于 扩展 BeanFacotry 中 现 有 的 功能 。 

ApplicationContext 和 BeanFacotry 两 者 都 是 用 于 加 载 Bean 的 ， 但 是 
相 比 之 下 ，Application Context 提 供 了 更 多 的 扩展 功能 ， 简 单一 点 说 : 
ApplicationContext 包 含 BeanFactory 的 所 有 功能 。 通 单 建议 比 
BeanFactory 优先 ， 除 非 在 一 些 限制 的 场合 ， 比 如 字 节 长 度 对 内 存 有 很 


大 的 影响 时 (Applet) 。 绝 大 多 数 “ 典 型 的 ”企业 应 用 和 系统 ， 
ApplicationContext 就 是 你 需要 使 用 的 。 
那么 究竟 ApplicationContext 比 BeanFactory 多 出 了 哪些 功能 呢 ? 
还 需要 我 们 进一步 的 探索 。 首 先 我 们 来 看 看 使 用 两 个 不 同 的 类 去 加 载 
配置 文件 在 写法 上 的 不 同 。 
使 用 BeanFactory 方 式 加 载 XML。 
BeanFactory bf = new XmlBeanFactory(new 
ClassPathResource("beanFactoryTest.xml")); 
使 用 ApplicationContext 方 式 加 载 XML。 
ApplicationContext bf = new 
ClassPathXmlApplicationContext("beanFactoryTest.xml"); 
同样 ， 我 们 还 是 以 ClassPathXmlApplicationContext 作 为 切入 点 ， 
开始 对 整体 功能 进行 分 析 。 
public ClassPathXmlApplicationContext(String configLocation) 
throws BeansException { 
this(new String[] {configLocation}, true, null); 
} 
public ClassPathXmlApplicationContext(String[] configLocations, 
boolean refresh, 
ApplicationContext parent) throws BeansException { 
super(parent); 
setConfigLocations(configLocations); 
if (refresh) { 
refresh(); 


设置 路 径 是 必 不 可 少 的 步骤 ，ClassPathXmlApplicationContext 中 
可 以 将 配置 文件 路 径 以 数组 的 方式 传 入 ， 
ClassPathXmlApplicationContext 可 以 对 数组 进行 解析 并 进行 加 载 。 而 
对 于 解析 及 功能 实现 都 在 refresh() 中 实现 。 


* 


6.1 


在 ClassPathXmlApplicationContext 中 支持 多 个 配置 文件 以 数组 方 
式 同时 传 入 : 
public void setConfigLocations(String[] locations) { 
if (locations != null) { 
Assert.noNullElements(locations, "Config locations must not be 
null"); 
this.configLocations = new String[locations.length]; 
for (int i = 0; i < locations.length; i++) { 
/解析 给 定 路 径 


this.configLocations[i] = resolvePath(locations[i |).trim(); 


j 
else { 


this.configLocations - null; 


) 

此 函数 主要 用 于 解析 给 定 的 路 径 数组 ， 当 然 ， 如 果 数 组 中 包含 特 
殊 符号 ， 如 ${var}， 那 么 在 resolvePath 中 会 搜寻 匹配 的 系统 变量 并 替 
换 。 


6.2 扩展 功能 


设置 了 路 径 之 后 ， 便 可 以 根据 路 径 做 配置 文件 的 解析 以 及 各 种 功 
能 的 实现 了 。 可 以 说 refresh 遂 数 中 包含 了 几乎 ApplicationContext 中 提 
供 的 全 部 功能 ， 而 且 此 阅 数 中 逻辑 非常 清晰 明了 ， 使 我 们 很 容易 分 析 
对 应 的 层次 及 逻辑 。 
public void refresh() throws BeansException, IllegalStateException 1 
synchronized (this.startupShutdownMonitor) 1 
/准备 刷新 的 上 下 文 环境 
prepareRefresh(); 
// Tell the subclass to refresh the internal bean factory. 
/初始 化 BeanFactory， 并 进行 XML 文件 读 取 
ConfigurableListableBeanFactory beanFactory = 
obtainFreshBeanFactory(); 
// Prepare the bean factory for use in this context. 
/对 BeanFactory 进 行 各 种 功能 填充 
prepareBeanFactory(beanFactory); 
try { 
// Allows post-processing of the bean factory in context 
subclasses. 
/ 子 类 覆盖 方法 做 额外 的 处 理 
postProcessBeanFactory(beanFactory); 
/激活 各 种 BeanFactory 处 理 器 
invokeBeanFactoryPostProcessors(beanFactory); 
/ 注册 拦截 Bean 创 建 的 Bean 处 理 器 ,这 里 只 是 注册 ， 真 正 的 
调用 是 在 getBean 时 候 
registerBeanPostProcessors(beanFactory); 
/为 上 下 文 初始 化 Message 源 ， 即 不 同 语言 的 消息 体 ， 
际 化 处 理 


initMessageSource(); 

// Initialize event multicaster for this context. 

/ 初始 化 应 用 消息 广播 器 ， 并 放 入 
*applicationEventMulticaster"beanFH 

initApplicationEventMulticaster(); 

// Initialize other special beans in specific context subclasses. 

// 留 给 子 类 来 初始 化 其 它 的 Bean 
onRefresh(); 
// Check for listener beans and register them. 
/在 所 有 注册 的 bean 中 查找 Listener bean， 注 册 到 消息 广 

播 器 中 

registerListeners(); 

// Instantiate all remaining (non-lazy-init) singletons. 

/ 初始 化 剩 下 的 单 实例 〈 非 惰性 的 ) 

finishBeanFactoryInitialization(beanFactory); 

// Last step: publish corresponding event. 

/ 完成 刷新 过 程 ， 通 知 生命 周期 处 理 器 lifecycleProcessor 
刷新 过 程 ， 同 时 发 出 

ContextRefreshEvent 通 知 别人 

finishRefresh(); 

j 
catch (BeansException ex) 1 

// Destroy already created singletons to avoid dangling 
resources. 

destroyBeans(); 

// Reset 'active' flag. 


cancelRefresh(ex); 


// Propagate exception to caller. 


throw ex; 


j 

下 面 概括 一 下 ClassPathXmlApplicationContext 初 始 化 的 步 又， 并 
从 中 解释 一 下 它 为 我 们 提供 的 功能 。 

(1) 初始 化 前 的 准备 工作 ， 例 如 对 系统 属性 或 者 环境 变量 进行 准 
备 及 验证 。 

在 某 种 情况 下 项 目的 使 用 需要 读 取 某 些 系统 变量 ， 而 这 个 变量 的 
设置 很 可 能 会 影响 着 系统 的 正确 性 ， 那 么 
ClassPathXmlApplicationContext 为 我 们 提供 的 这 个 准备 函数 就 显得 非 


单 必要 ， 它 可 以 在 Spring 启动 的 时 候 提前 对 必须 的 变量 进行 存在 性 验 
证 。 


(2) 初始 化 BeanFactory， 并 进行 XML 文件 读 取 。 

之 前 有 提 到 ClassPathXmlApplicationContext 包 含 着 BeanFactory 所 
提供 的 一 切 特征 ， 那 么 在 这 一 步 又 中 将 会 复 用 BeanFactory 中 的 配置 
文件 读 取 解析 及 其 他 功能 ， 这 一 步 之 后 ， 
ClassPathXmlApplicationContext 实际 上 就 已 经 包含 了 BeanFactory 所 提 
供 的 功能 ， 也 就 是 可 以 进行 Bean 的 提取 等 基础 操作 了 。 

(3) 对 BeanFactory 进 行 各 种 功能 填充 。 

@Qualifier 与 @Autowired 应 该 是 大 家 非常 熟悉 的 注解 ， 那 么 这 两 

个 注解 正 是 在 这 一 步骤 中 增加 的 支持 。 
(4) 子 类 和 覆盖 方法 做 额外 的 处 理 。 

Spring 之 所 以 强大 ， 为 世人 所 推崇 ， 除 了 它 功 能 上 为 大 家 提供 了 
便 例 外 ， 还 有 一 方面 是 它 的 完美 架构 ， 开 放 式 的 架构 让 使 用 它 的 程序 
员 很 容易 根据 业务 需要 扩展 已 经 存在 的 功能 。 这 种 开放 式 的 设计 在 


Spring 中 随处 可 见 ， 例 如 在 本 例 中 就 提供 了 一 个 空 的 函数 实现 
postProcess BeanFactory 来 方便 程序 员 在 业务 上 做 进一步 扩展 。 

(5) 激活 各 种 BeanFactory 处 理 器 。 

(6) 注册 拦截 bean 创 建 的 bean 处 理 器 ， 这 里 只 是 注册 ， 真 正 的 调 
用 是 在 getBean 时 候 。 

(7) 为 上 下 文 初始 化 Message 源 ， 即 对 不 同 语言 的 消息 体 进 行 国 
际 化 处 理 。 

(8) 初始 化 应 用 消息 广播 器 ， 并 放 入 
*applicationEventMulticaster"beanFH 

(9) 留 给 子 类 来 初始 化 其 他 的 bean。 

(10) 在 所 有 注册 的 bean 中 查找 listener bean， 注 册 到 消息 广播 器 
中 。 

(11) 初始 化 剩 下 的 单 实例 〈 非 惰性 的 ) 。 

(12) 完成 刷新 过 程 ， 通 知 生 命 周 期 处 理 器 lifecycleProcessor 刷 新 
过 程 ， 同 时 发 出 Context RefreshEvent 通 知 别人 。 


6.3 环境 准备 


prepareRefresh 峭 | 数 主要 是 做 些 准备 工作 ， 例 如 对 系统 属性 及 环境 
变量 的 初始 化 及 验证 。 
protected void prepareRefresh() { 
this.startupDate = System.currentTimeMillis(); 
synchronized (this.activeMonitor) { 
this.active = true; 
} 
if (logger.isInfoEnabled()) 1 
logger.info("Refreshing " + this); 


j 
BAF REE 
initPropertySources(); 
/验证 需要 的 属性 文件 是 否 都 已 经 放 入 环境 中 
getEnvironment().validateRequiredProperties(); 
j 
网 上 有 人 说 其 实 这 个 函数 没什么 用 ， 因 为 最 后 两 名 代码 才 是 最 为 
关键 的 ， 但 是 却 没有 什么 逻辑 处 理 ，initPropertySources 是 空 的 ， 没 有 
任何 人 逻辑， 而 getEnvironment().validateRequiredProperties 也 因为 没有 需 
要 验证 的 属性 而 没有 做 任何 处 理 。 其 实 这 都 是 因为 没有 彻底 理解 才 会 
这 么 说 ， 这 个 函数 如 果 用 好 了 作用 还 是 挺 大 的 。 那 么 ， 该 怎么 用 呢 ? 
我 们 先 探索 下 各 个 函数 的 作用 。 
(1) initPropertySources 正 符合 Spring 的 开放 式 结构 设计 ， 给 用 户 
最 大 扩展 Spring 的 能 力 。 用 户 可 以 根据 自身 的 需要 重 写 
initPropertySources 方法 ， 并 在 方法 中 进行 个 性 化 的 属性 处 理 及 设置 。 
(2) validateRequiredProperties 则 是 对 属性 进行 验证 ， 那 么 如 何 
验证 呢 ? 我 们 举 个 融合 两 名 代码 的 小 例子 来 帮助 大 家 理解 。 
假如 现在 有 这 样 一 个 需求 ， 工 程 在 运行 过 程 中 用 到 的 某 个 设 
(例如 VAR) 是 从 系统 环境 变量 中 取得 的 ， 而 如 果 用 户 没有 在 系统 环 
境 变量 中 配置 这 个 参数 ， 那 么 工程 可 能 不 会 工作 。 这 一 要 求 可 能 会 
各 种 各 样 的 解决 办 法 ， 当 然 ， 在 Spring 中 可 以 这 样 做 ， 你 可 以 直接 修 
改 Spring 的 源码 ， 例 如 修改 ClassPathXmlApplicationContext。 当然， 最 
好 的 办 法 还 是 对 源码 进行 扩展 ， 我 们 可 以 自 定义 类 : 
public class MyClassPathXmlApplicationContext extends 
ClassPathXmlApplicationContext{ 
public MyClassPathXmlApplicationContext(String... 


configLocations ){ 


super(configLocations); 

i 

protected void initPropertySources() { 

/添加 验证 要 求 
getEnvironment().setRequiredProperties(" VAR"); 


j 
我 们 自 定 义 了 继承 自 ClassPathXmlApplicationContext 的 
MYyClassPathXmlApplicationContext， 并 重 写 了 initPropertySources FA 
法 ， 在 方法 中 添加 了 我 们 的 个 性 化 需求 ， 那 么 在 验证 的 时 候 也 就 是 程 
序 走 到 getEnvironment().validateRequiredProperties() 代 码 的 时 候 ， 如 果 
系统 并 没有 检测 到 对 应 VAR 的 环境 变量 ， 那 么 将 抛 出 异常 。 当 然 我 们 
还 需要 在 使 用 的 时 候 蔡 换 掉 原 有 的 ClassPathXmlApplicationContext: 
public static void main(String[] args) { 
ApplicationContext bf = new MyClassPathXmlApplicationContext 
("test/customtag/ 
test.xml"); 
User user=(User) bf.getBean("testbean"); 
} 


6.4 加 载 BeanFactory 


obtainFreshBeanFactory 方法 从 字面 理解 是 获取 BeanFactory。 之 前 
有 说 过 ， Application Context 是 对 BeanFactory 的 功能 上 的 扩展 ， 不 但 包 
含 了 BeanFactory 的 全 部 功能 更 在 其 基础 上 添加 了 大 量 的 扩展 应 用 ， 那 
么 obtainFreshBeanFactory 正 是 实现 BeanFactory 的 地 方 ， 也 就 是 经 过 了 
这 个 函数 后 ApplicationContext 就 已 经 拥有 了 BeanFactory 的 全 部 功能 。 


protected ConfigurableListableBeanFactory obtainFreshBeanFactory() 


/初始 化 BeanFactory， 并 进行 XML 文件 读 取 , 并 将 得 到 的 
BeanFacotry 记 录 在 当前 实体 的 属性 中 
refreshBeanFactory(); 
/返回 当前 实体 的 beanFactory 属 性 
ConfigurableListableBeanFactory beanFactory = getBeanFactory(); 
if (logger.isDebugEnabled()) 1 
logger.debug(" Bean factory for " + getDisplayName() + ": "+ 
beanFactory); 
i 
return beanFactory; 
j 
方法 中 将 核心 实现 委托 给 了 refreshBeanFactory: 
@Override 
protected final void refreshBeanFactory() throws BeansException { 
if (hasBeanFactory()) { 
destroyBeans(); 
closeBeanFactory(); 
} 
try { 
/创建 DefaultListableBeanFactory 
DefaultListableBeanFactory beanFactory = createBeanFactory(); 
/为 了 序列 化 指定 id， 如 果 需 要 的 话 , 让 这 个 BeanFactory 从 id 反 
序列 化 到 BeanFactory 对 象 
beanFactory.setSerializationId(getId()); 


/定制 beanFactory， 设 置 相关 属性 ， 包 括 是 否 允 许 覆 盖 同 名 称 
的 不 同 定义 的 对 象 以 及 循环 依赖 以 及 

/设置 @Autowired 和 @Qualifier 注解 解析 器 
QualifierAnnotationAutowire 

CandidateResolver 

customizeBeanFactory(beanFactory); 

/初始 化 DodumentReader， 并 进行 XML 文件 读 取 及 解析 

loadBeanDefinitions(beanFactory); 

synchronized (this.beanFactoryMonitor) 1 


this.beanFactory = beanFactory; 


} 
catch (IOException ex) { 
throw new ApplicationContextException("I/O error parsing bean 
definition 


source for " + getDisplayName(), ex); 


} 
我 们 详细 分 析 上 面 的 每 个 步骤 。 
(1) 创建 DefaultListableBeanFactory。 
在 介绍 BeanFactory 的 时 候 ， 不 知道 读者 是 否 还 有 印象 ， 声 明 方 式 
为 : BeanFactory bf = new XmlBeanFactory("beanFactoryTest.xml"), H 
中 的 XmlBeanFactory 继 承 自 DefaultListableBean Factory， 并 提供 了 
XmlBeanDefinitionReader 类 型 的 reader 属 性 ， 也 就 是 说 
DefaultListableBean Factory 是 容器 的 基础 。 必 须 首 先 要 实例 化 ， 那 么 
在 这 里 就 是 实例 化 DefaultListableBeanFactory 的 步骤 。 
(2) 指定 序列 化 ID。 


(3) 定制 BeanFactory。 
(4) 加 载 BeanDefinition。 
(5) 使 用 全 局 变量 记录 BeanFactory 类 实例 。 
为 DefaultListableBeanFactory 类 型 的 变量 beanFactory 是 函数 内 的 
局 部 变量 ， 所 以 要 使 用 全 局 变量 记录 解析 结果 。 


6.4.1 定制 BeanFactory 


这 里 已 经 开始 了 对 BeanFactory 的 扩展 ， 在 基本 容器 的 基础 上 ， 
增加 了 是 否 允 许 履 盖 是 否 允 许 扩 展 的 设置 并 提供 了 注解 @Qualifier 和 
@Autowired 的 支持 。 

protected void customizeBeanFactory(DefaultListableBeanFactory 
beanFactory) { 

/如 果 属 性 allowBeanDefinitionOverriding 不 为 空 ， 设 置 给 
beanFactory 对 象 相应 属性 ， 
/此 属性 的 含义 : 是 否 允 许 覆 了 荔 同 名 称 的 不 同 定义 的 对 象 


if (this.allowBeanDefinitionOverriding != null) { 


beanFactory.setAllowBeanDefinitionOverriding(this.allowBeanDefinitionO 
verriding); 

} 

/如 果 属 性 allowCircularReferences 不 为 空 ， 设 置 给 beanFactory 对 
象 相应 属性 ， 

/此 属性 的 含义 : 是 否 允 许 bean 之 间 存 在 循环 依赖 


if (this.allowCircularReferences !- null) { 


beanFactory.setAllowCircularReferences(this.allowCircularReferences); 


} 


/用 于 @Qualifier 和 @Anutowired 
beanFactory.setAutowireCandidateResolver(new 
QualifierAnnotationAutowire 
Candidate Resolver()); 
j 
对 于 允许 覆盖 和 人 允许 依赖 的 设置 这 里 只 是 判断 了 是 否 为 空 ， 如 果 
不 为 空 要 进行 设置 ， 但 是 并 没有 看 到 在 哪里 进行 设置 ， 究 竟 这 个 设置 
是 在 哪里 进行 设置 的 呢 ? 还 是 那 句 话 ， 使 用 子 类 覆盖 方法 ， 例 如 : 
public class MyClassPathXmlApplicationContext extends 
ClassPathXmlApplicationContext{ 
protected void customizeBeanFactory(DefaultListableBeanFactory 
beanFactory) { 
super.setAllowBeanDefinitionOverriding(false); 
super.setAllowCircularReferences(false); 


super.customizeBeanFactory(beanFactory); 


} 

设置 完 后 相信 大 家 已 经 对 于 这 两 个 属性 的 使 用 有 所 了 解 ， 或 者 可 
以 回 到 前 面 的 章节 进行 再 一 次 查看 。 对 于 定制 BeanFactory，Spring 还 
提供 了 另外 一 个 重要 的 扩展 ， 就 是 设置 Autowire CandidateResolver， 
在 bean 加 载 部 分 中 讲解 创建 Bean 时 ， 如 果 采 用 autowireByType 方 式 注 
入 ， 那 么 默认 会 使 用 Spring 提 供 的 SimpleAutowireCandidateResolver， 
而 对 于 默认 的 实现 并 没有 过 多 的 逻辑 处 理 。 在 这 里 ，Spring 使 用 了 
QualifierAnnotationAutowireCandidateResolver， 设 置 了 这 个 解析 器 后 


Spring 就 可 以 支持 注解 方式 的 注入 了 。 


在 讲解 根据 类 型 自 定 注 入 的 时 候 ， 我 们 说 过 解析 autowire 类 型 时 首 
先 会 调用 方法 : 
Object value = 
getAutowireCandidateResolver().getSuggested Value(descriptor); 
因此 我 们 知道 ， 在 QualifierAnnotationAutowireCandidateResolver 
中 一 定 会 提供 了 解析 Qualifier 与 Autowire 注 解 的 方法 。 
QualifierAnnotationAutowireCandidateResolver.java 
public Object getSuggestedValue(DependencyDescriptor descriptor) 1 
Object value = findValue(descriptor.getAnnotations()); 
if (value == null) 1 
MethodParameter methodParam = 
descriptor.getMethodParameter(); 
if (methodParam != null) { 
value = findValue(methodParam.getMethodAnnotations()); 


} 


return value; 


j 
6.4.2 BeanDefinition 


在 第 一 步 中 提 到 了 将 ClassPathXmlApplicationContext 与 
XmlBeanFactory 创 建 的 对 比 ， 在 实现 配置 文件 的 加 载 功 能 中 除了 我 们 
在 第 一 步 中 已 经 初始 化 的 DefaultListableBeanFactory 外 ， 还 需 
XmlBeanDefinitionReader 来 读 取 XML ， 那 么 在 这 个 步骤 中 首先 要 做 
的 就 是 初始 化 XmlBeanDefinitionReader。 

@Override 


protected void loadBeanDefinitions(DefaultListableBeanFactory 
beanFactory) throws 
BeansException, IOException 1 
/为 指定 beanFactory 创 建 XmlBeanDefinitionReader 
XmlBeanDefinitionReader beanDefinitionReader = new 
XmlBeanDefinitionReader(beanFactory); 
/对 beanDefinitionReader 进 行 环境 变量 的 设置 
beanDefinitionReader.setEnvironment(this.getEnvironment()); 
beanDefinitionReader.setResourceLoader(this); 
beanDefinitionReader.setEntityResolver(new 
ResourceEntityResolver(this)); 
/对 BeanDefinitionReader 进 行 设置 ， 可 以 覆盖 
initBeanDefinitionReader(beanDefinitionReader); 
loadBeanDefinitions(beanDefinitionReader); 
j 
在 初始 化 了 DefaultListableBeanFactory 和 XmlBeanDefinitionReader 
后 就 可 以 进行 配置 文件 的 读 取 了 。 


protected void loadBeanDefinitions( XmlBeanDefinitionReader reader) 


throws BeansException, 
IOException 1 
Resource[] configResources = getConfigResources(); 
if (configResources != null) { 
reader.loadBeanDefinitions(configResources); 
} 
String[] configLocations = getConfigLocations(); 
if (configLocations != null) { 


reader.loadBeanDefinitions(configLocations); 


} 

使 用 XmlBeanDefinitionReader 的 loadBeanDefinitions 方 法 进行 配置 
文件 的 加 载 机 注册 相信 大 家 已 经 不 陌生 ， 这 完全 就 是 开始 BeanFactory 
的 套路 。 因 为 在 XmlBeanDefinitionReader 中 已 经 将 之 前 初始 化 的 
DefaultListableBeanFactory 注 册 进 去 了 ， 所 以 XmlBeanDefinitionReader 
所 读 取 的 BeanDefinitionHolder 都 会 注册 到 DefaultListableBeanFactory 
中 ， 也 就 是 经 过 此 步骤 ， 类 型 DefaultListableBeanFactory 的 变量 
beanFactory 已 经 包含 了 所 有 解析 好 的 配置 。 


6.5 功能 扩展 


进入 图 数 prepareBeanFactory 前 ，Spring 已 经 完成 了 对 配置 的 解 
析 ， 而 ApplicationContext 在 功能 上 的 扩展 也 由 此 展开 。 
protected void prepareBeanFactory(ConfigurableListableBeanFactory 
beanFactory) 1 
/设置 beanFactory 的 classLoader 为 当前 context 的 classLoader 
beanFactory.setBeanClassLoader(getClassLoader()); 
/设置 beanFactory 的 表达 式 语言 处 理 器 ，Spring3 增 加 了 表达 陈 
语言 的 支持 ， 
// 默 认可 以 使 用 #{bean.xxx} 的 形式 来 调用 相关 属性 值 。 
beanFactory.setBeanExpressionResolver(new 
StandardBeanExpressionResolver()); 
/为 beanFactory 增 加 了 一 个 默认 的 propertyEditor， 这 个 主要 是 对 
bean 的 属性 等 设置 管理 的 一 
个 工具 


beanFactory.addPropertyEditorRegistrar(new 
ResourceEditorRegistrar(this, 
getEnvironment())); 
/* 
* 添加 BeanPostProcessor， 
"i 
beanFactory.addBeanPostProcessor(new 


ApplicationContextAwareProcessor(this)); 


/设置 了 几 个 忽略 自动 装配 的 接口 


beanFactory.ignoreDependencyInterface(ResourceLoaderAware.class); 


beanFactory.ignoreDependencyInterface(ApplicationEventPublisherAware. 


class); 


beanFactory.ignoreDependencyInterface(MessageSourceAware.class); 


beanFactory.ignoreDependencyInterface(ApplicationContextAware.class); 
beanFactory.ignoreDependencyInterface(EnvironmentAware.class); 
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beanFactory.registerResolvableDependency(BeanFactory.class, 
beanFactory); 
beanFactory.registerResolvableDependency(ResourceLoader.class, 
this); 


beanFactory.registerResolvableDependency(ApplicationEventPublisher.clas 


s, this); 


beanFactory.registerResolvableDependency(A pplicationContext.class, 
this); 
/增加 对 Aspect 的 支持 
if 
(beanFactory.containsBean(LOAD TIME WEAVER BEAN NAME)) 1 
beanFactory.addBeanPostProcessor(new 
LoadTimeWeaverAwareProcessor(beanFactory)); 
// Set a temporary ClassLoader for type matching. 
beanFactory.setTempClassLoader(new 
ContextTypeMatchClassLoader (beanFactory. 
getBeanClassLoader())); 


} 
/添加 默认 的 系统 环境 bean 
if 


(!IbeanFactory.containsLocalBean(ENVIRONMENT BEAN NAME)) { 


beanFactory.registerSingleton(ENVIRONMENT BEAN NAME, 
getEnvironment()); 

j 

if 
(!IbeanFactory.containsLocalBean(SYSTEM PROPERTIES BEAN NAM 
E) t 


beanFactory.registerSingleton(SYSTEM PROPERTIES BEAN NAME, 
getEnvironment(). 


getSystemProperties()); 


} 

if 
(!IbeanFactory.containsLocalBean(SYSTEM ENVIRONMENT BEAN N 
AME)) { 


beanFactory.registerSingleton(SYSTEM ENVIRONMENT BEAN NAM 
E, getEnvironment(). 


getSystemEnvironment()); 


j 
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增加 对 SPEL 语 言 的 支持 。 

增加 对 属性 编辑 器 的 支持 。 

增加 对 一 些 内 置 类 ， 比 如 EnvironmentAware、 
MessageSourceAware 的 信息 注入 。 

设置 了 依赖 功能 可 忽略 的 接口 。 

注册 一 些 固定 依赖 的 属性 。 

增加 AspectJ 的 支持 (会 在 第 7 章 中 进行 详细 的 讲解 ) 。 

将 相关 环境 变量 及 属性 注册 以 单 例 模式 注册 。 

可 能 读者 不 是 很 理解 每 个 步骤 的 具体 含义， 接 下 来 我 们 会 对 各 个 
步骤 进行 详细 地 分 析 。 

6.5.1 增加 SPEL 语言 的 支持 


Spring 表 达 式 语言 全 称 为 “Spring Expression Language”， 缩 写 为 
“SpEL”， 类 似 于 Struts 2x 中 使 用 的 OGNL 表 达 式 语言 ， 能 在 运行 时 构建 
复杂 表达 式 、 存 取 对 象 图 属性 、 对 象 方 法 调用 等 ， 并 且 能 与 Spring 功 


能 完美 整合 ， 比 如 能 用 来 配置 bean 定 义 。SpEL 是 单独 模块 ， 只 依赖 于 
core 模 块 ， 不 依赖 于 其 他 模块 ， 可 以 单独 使 用 。 

SpEL 使 用 #{...} 作 为 定 界 符 ， 所 有 在 大 框 号 中 的 字符 都 将 被 认为 
是 SpEL， 使 用 格式 如 下 : 

<bean id="saxophone" value-"com.xxx.xxx. Xxx"/» 

<bean > 

<property name-"instrument" value="#{saxophone}"/> 

<bean/> 

相当 于 : 

<bean id="saxophone" value-"com.xxx.xxx. Xxx"/» 

<bean > 

<property name-"instrument" ref="saxophone"/> 

<bean/> 

当然 ， 上 面 只 是 列举 了 其 中 最 简单 的 使 用 方式 ，SPEL 功 能 非常 强 
大 ， na crede 高 开发 效率 ， 这 里 只 为 唤起 读者 的 记忆 来 帮助 
我 们 理解 源码 ， 有 兴趣 的 读者 可 以 进一步 深入 研究 

在 源码 中 通过 代码 beanFactory.setBeanExpressionResolver(new 
StandardBeanExpression ResolverO) 注 册 语 言 解析 器 ， 就 可 以 对 SPEL 进 
行 解析 了 ， 那 么 在 注册 解析 器 后 Spring 又 是 在 什么 时 候 调 用 这 个 解析 
器 进行 解析 呢 ? 

之 前 我 们 讲解 过 Spring 在 bean 进行 初始 化 的 时 候 会 有 属性 填充 
的 一 步 ， 而 在 这 一 步 中 Spring 会 调用 
AbstractAutowireCapableBeanFactory3¢AYapplyProperty Values ŠR T 
成 功能 。 就 在 这 个 函数 中 ， 会 通过 构造 BeanDefinitionValueResolver 类 
型 实例 valueResolver 来 进行 属性 值 的 解析 。 同 时 ， 也 是 在 这 个 步骤 中 
一 般 通 过 AbstractBeanFactory 中 的 evaluateBeanDefinitionString 方 法 去 
完成 SPEL 的 解析 。 


protected Object evaluateBeanDefinitionString(String value， 

BeanDefinition beanDefinition) ( 

if (this.beanExpressionResolver == null) 1 

return value; 

j 

Scope scope = (beanDefinition !- null ? 
getRegisteredScope(beanDefinition.getScope()) : 

null); 

return this.beanExpressionResolver.evaluate(value, new 
BeanExpressionContext(this, 

scope)); 

} 

当 调用 这 个 方法 时 会 判断 是 否 存在 语言 解析 器 ， 如 果 存 在 则 调用 
语言 解析 器 的 方法 进行 解析 ， 解 析 的 过 程 是 在 Spring 的 expression 的 包 
内 ， 这 里 不 做 过 多 解释 。 我 们 通过 查看 对 evaluate BeanDefinitionString 
方法 的 调用 层次 可 以 看 出 ， 应 用 语言 解析 器 的 调用 主要 是 在 解析 依赖 
注入 bean 的 时 候 ， 以 及 在 完成 bean 的 初始 化 和 属性 获取 后 进行 属性 填 
充 的 时 候 。 

6.5.2 增加 属性 注册 编辑 器 

在 Spring DI 注入 的 时 候 可 以 把 普通 属性 注入 进来 ， 但 是 像 Date 类 
型 就 无 法 被 识别 。 例 如 : 

public class UserManager { 

private Date data Value; 
public Date getDataValue() 1 


return data Value; 


public void setDataValue(Date data Value) 1 
this.dataValue = dataValue; 
i 
public String toString(){ 


return "dataValue: " + dataValue; 


j 

上 面 代 码 中 ， 需 要 对 日 期 型 属性 进行 注入 : 

<bean id="userManager" class="com.test. UserManager"> 

«property name="dataValue"> 
<value>2013-03-15</value> 
</property> 

</bean> 

测试 代码 : 

@Test 

public void testDate()1 

ApplicationContext ctx = new 
ClassPathXmlApplicationContext("beans.xml"); 

UserManager userManager = 
(UserManager)ctx.getBean("userManager"); 

System.out.printIn(userManager); 

} 

如 果 直 接 这 样 使 用 ， 程 序 则 会 报 异 常 ， 类 型 转换 不 成 功 。 因 为 在 
UserManager 中 的 dataValue 属 性 是 Date 类 型 的 ， 而 在 XML 中 配置 的 却 
是 String 类 型 的 ， 所 以 当然 会 报 异 常 。 

Spring 针对 此 问题 提供 了 两 种 解决 办 法 。 

1. 使 用 自 定义 属性 编辑 器 


使 用 自 定义 属性 编辑 器 ， 通 过 继承 PropertyEditorSupport， 重 写 
setAsText 方 法 ， 具 体 步 又 如 下 。 
(1) 编写 自 定 义 的 属性 编辑 器 。 
public class DatePropertyEditor extends PropertyEditorSupport { 
private String format = "yyyy-MM-dd"; 
public void setFormat(String format) { 
this.format = format; 
j 
public void setAsText(String arg0) throws 
IllegalArgumentException 1 
System.out.printIn("arg0: " + arg0); 
SimpleDateFormat sdf = new SimpleDateFormat(format); 


try 1 
Date d = sdf.parse(arg0); 
this.setValue(d); 


} catch (ParseException e) 1 


e.printStackTrace(); 


j 
(2) 将 自 定 义 属性 编辑 器 注册 到 Spring 中 。 
<!-- 自 定义 属性 编辑 器 --> 
<bean 
class-"org.Springframework.beans.factory.config.CustomEditorConfigurer 
"> 
<property name="customEditors"> 


<map> 


«entry key="java.util.Date"> 
<bean class-"com.test.DateProperty Editor" ^ 
«property name-"format" value="yyyy-MM-dd"/> 
</bean> 
</entry> 
</map> 
</property> 
</bean> 
在 配置 文件 中 引入 类 型 为 
org.Springframework.beans.factory.config.CustomEditorConfigurer 的 
bean， 并 在 属性 customEditors 中 加 入 自 定 义 的 属性 编辑 器 ， 其 中 key 为 
属性 编辑 器 所 对 应 的 类 型 。 通 过 这 样 的 配置 ， 当 Spring 在 注入 bean 的 
属性 时 一 旦 遇 到 了 java.util.Date 类 型 的 属性 会 自动 调用 自 定义 的 
DatePropertyEditor 解析 器 进行 解析 ， 并 用 解析 结果 代替 配置 属性 进行 
注入 。 
2。 注 册 Spring 自 带 的 属性 编辑 器 CustomDateEditor 
通过 注册 Spring 自 带 的 属性 编辑 器 CustomDateEditor， 具 体 步 又 如 
下 。 
(1) 定义 属性 编辑 器 。 
public class DatePropertyEditorRegistrar implements 
PropertyEditorRegistrar{ 
public void registerCustomEditors(PropertyEditorRegistry registry) 


registry.registerCustomEditor(Date.class, new 
CustomDateEditor(new SimpleDateFormat 
("yyyy-MM-dd"),true)); 


j 
(2) 注册 到 Spring 中 。 

<!-- 注 册 Spring 自 带 编 辑 器 --> 

<bean 
class-"org.Springframework.beans.factory.config.CustomEditorConfigurer 
"> 

<property name="propertyEditorRegistrars"> 
<list> 
<bean class="com.test.DatePropertyEditorRegistrar"></bean> 
</list> 
</property> 

</bean> 

通过 在 配置 文件 中 将 自 定义 的 DatePropertyEditorRegistrar 注册 进 
入 org.Springframework. beans.factory.config.CustomEditorConfigurer 的 
propertyEditorRegistrars 属 性 中 ， 可 以 具有 与 方法 1 同样 的 效果 。 

我 们 了 解 了 自 定 义 属 性 编辑 器 的 使 用 ， 但 是 ， 似 乎 这 与 本 节 中 
绕 的 核心 代码 beanFactory.add PropertyEditorRegistrar(new 
ResourceEditorRegistrar(this, getEnvironment())) 并 无 联系 ， 因 为 在 注册 
自 定义 属性 编辑 器 的 时 候 使 用 的 是 PropertyEditorRegistry 的 
registerCustomEditor 方 法 ， 而 这 里 使 用 的 是 
ConfigurableListableBeanFactory 的 addPropertyEditorRegistrar 方 法 。 我 
们 不 妨 深入 探索 一 下 ResourceEditorRegistrar 的 内 部 实现 ， 在 
ResourceEditorRegistrar 中 ， 我 们 最 关心 的 方法 是 
registerCustomEditorso 

public void registerCustomEditors(Property EditorRegistry registry) 1 

ResourceEditor baseEditor = new 


ResourceEditor(this.resourceLoader, this. 


property Resolver); 

doRegisterEditor(registry, Resource.class, baseEditor); 

doRegisterEditor(registry, ContextResource.class, baseEditor); 

doRegisterEditor(registry, InputStream.class, new 
InputStreamEditor(baseEditor)); 

doRegisterEditor(registry, InputSource.class, new 
InputSourceEditor(baseEditor)); 

doRegisterEditor(registry, File.class, new FileEditor(baseEditor)); 

doRegisterEditor(registry, URL.class, new 
URLEditor(baseEditor)); 

ClassLoader classLoader = this.resourceLoader.getClassLoader(); 

doRegisterEditor(registry, URI.class, new URIEditor(classLoader)); 

doRegisterEditor(registry, Class.class, new 
ClassEditor(classLoader)); 

doRegisterEditor(registry, Class[].class, new 
Class ArrayEditor(classLoader)); 

if (this.resourceLoader instanceof ResourcePatternResolver) { 

doRegisterEditor(registry, Resource[].class, 
new ResourceArrayPropertyEditor((ResourcePatternResolver) 

this. 


resourceLoader, this.propertyResolver)); 


private void doRegisterEditor(PropertyEditorRegistry registry, Class<? 
> requiredType, 
PropertyEditor editor) { 
if (registry instanceof PropertyEditorRegistrySupport) { 


((PropertyEditorRegistrySupport) registry).overrideDefaultEditor 
(requiredType, 
editor); 
} 
else { 


registry.registerCustomEditor(requiredType, editor); 


} 

在 doRegisterEditor 函数 中 ， 可 以 看 到 在 之 前 提 到 的 自 定 义 属 性 中 
使 用 的 关键 代码 : registry.registerCustomEditor(requiredType, editor), 
回 过 头 来 看 ResourceEditorRegistrar 类 的 registerCustomEditors 方 法 的 核 

心 功能 ， 其 实 无 非 是 注册 了 一 系列 的 常用 类 型 的 属性 编辑 器 ， 例 如 ， 
代码 doRegisterEditor(registry, Class.class, new ClassEditor(classLoader)) 
实现 的 功能 就 是 注册 Class 类 对 应 的 属性 编辑 器 。 那 么 ， 注 册 后 ， 一 旦 
某 个 实体 bean 中 存在 一 些 Class 类 型 的 属性 ， 那 么 Spring 会 
ClassEditor 将 配置 中 定义 的 String 类 型 转换 为 Class 类 型 并 进行 赋值 。 

分 析 到 这 里 ， 我 们 不 禁 有 个 疑问 ， 虽 说 ResourceEditorRegistrar 类 
的 registerCustomEditors 方 法 实现 了 批量 注册 的 功能 ， 但 是 
beanFactory.addPropertyEditorRegistrar(new ResourceEditorRegistrar(this, 
getEnvironmentO)) 仅 仅 是 注册 了 ResourceEditorRegistrar 实 例 ， 却 并 没 
有 调用 ResourceEditorRegistrar 的 registerCustomEditors 方法 进行 注册 ， 
那么 到 底 是 在 什么 时 候 进 行 注 册 的 呢 ? 进一步 查看 
ResourceEditorRegistrar 的 registerCustomEditors 方 法 的 调用 层次 结构 ， 
如 图 6-1 所 示 。 


© registerCustomEditors(PropertyEditorRegistry) : void - org.springframewc t.Re litorRegist 
registerCustomEditors(PropertyEditorRegistry) : void - org. mee m SEE x 


6-1 ResourceEditorRegistrar 的 registerCustomEditors 方 法 的 调用 层次 
结构 


发 现在 AbstractBeanFactory 中 的 registerCustomEditors 方法 中 被 调 
用 过 ， 继 续 查 看 AbstractBeanFactory 中 的 registerCustomEditors 方 法 的 调 
用 层次 结构 ， 如 图 6-2 所 示 。 


4 registerCustomEditors(PropertyEditorRegistry) : void - org. ning beans lactopa pneri ostro eaoka cin. 
© SPD RTOS g.spri amework.beans.factory.support.AbstractB eanFactory 
© getTypeConverter() : Typ t t org.s j c 
RB Ape eril EDU: oid - org.sp 


6-2 AbstractBeanFactory H B registerCustomEditors 方 法 的 调用 层次 结 
构 


其 中 我 们 看 到 一 个 方法 是 我 们 熟悉 的 ， 就 是 AbstractBeanFactory 
类 中 的 initBeanWrapper 方 法 ， 这 是 在 bean 初始 化 时 使 用 的 一 个 方法 ， 
之 前 已 经 使 用 过 大 量 的 篇 幅 进 行 讲 解 ， 主 要 是 在 将 BeanDefinition 转 换 
为 BeanWrapper 后 用 于 对 属性 的 填充 。 到 此 ， 逻 辑 已 经 明了 ， 在 bean 的 
初始 化 后 会 调用 ResourceEditorRegistrar 的 registerCustomEditors 方 法 进 
行 批量 的 通用 属性 编辑 器 注册 。 注 册 后 ， 在 属性 填充 的 环节 便 可 以 直 
接 让 Spring 使 用 这 些 编辑 器 进行 属性 的 解析 了 。 

既然 提 到 了 BeanWrapper， 这 里 也 有 必要 强调 下 ，Spring 中 用 于 封 
+ beanHy on ， 而 它 又 间接 继承 了 
PropertyEditorRegistry 类 型 ， 也 就 是 我 们 之 前 反复 看 到 的 方法 参数 
PropertyEditorRegistry registry， 其 实 大 部 分 情况 下 都 是 BeanWrapper; 
对 于 BeanWrapper 在 Spring 中 的 默认 实现 是 BeanWrapperImpl， 而 
BeanWrapperImpl 除 了 实现 BeanWrapper 接 口外 还 继承 了 
PropertyEditorRegistrySupport， 在 PropertyEditorRegistrySupport 中 有 这 
梓 一 个 方法 : 


private void createDefaultEditors() { 


(64); 


types. 


this.defaultEditors = new HashMap<Class<?>, PropertyEditor> 


// Simple editors, without parameterization capabilities. 


// The JDK does not contain a default editor for any of these target 


this.defaultEditors.put(Charset.class, new CharsetEditor()); 
this.defaultEditors.put(Class.class, new ClassEditor()); 
this.defaultEditors.put(Class[].class, new ClassArrayEditor()); 
this.defaultEditors.put(Currency.class, new CurrencyEditor()); 
this.defaultEditors.put(File.class, new FileEditor()); 


this.defaultEditors.put(InputStream.class, new 


InputStreamEditor()); 


this.defaultEditors.put(InputSource.class, new 


InputSourceEditor()); 


this.defaultEditors.put(Locale.class, new LocaleEditor()); 
this.defaultEditors.put(Pattern.class, new PatternEditor()); 
this.defaultEditors.put(Properties.class, new PropertiesEditor()); 


this.defaultEditors.put(Resource[].class, new 


ResourceArrayPropertyEditor()); 


this.defaultEditors.put(TimeZone.class, new TimeZoneEditor()); 
this.defaultEditors.put(URI.class, new URIEditor()); 
this.defaultEditors.put(URL.class, new URLEditor()); 
this.defaultEditors.put(UUID.class, new UUIDEditor()); 

// Default instances of collection editors. 


// Can be overridden by registering custom instances of those as 


custom editors. 


class)); 

this.defaultEditors.put(Collection.class, new 
CustomCollectionEditor (Collection. 

this.defaultEditors.put(Set.class, new 
CustomCollectionEditor(Set.class)); 

class)); 

this.defaultEditors.put(SortedSet.class, new 
CustomCollectionEditor (SortedSet. 

this.defaultEditors.put(List.class, new 
CustomCollectionEditor(List.class)); 

this.defaultEditors.put(SortedMap.class, new 
CustomMapEditor(SortedMap.class)); 

// Default editors for primitive arrays. 

this.defaultEditors.put(byte[].class, new 
ByteArrayPropertyEditor()); 

this.defaultEditors.put(char[].class, new 
CharArrayPropertyEditor()); 

// The JDK does not contain a default editor for char! 

this.defaultEditors.put(char.class, new CharacterEditor(false)); 

this.defaultEditors.put(Character.class, new CharacterEditor(true)); 

// Spring's CustomBooleanEditor accepts more flag values than the 
JDK's default editor. 

this.defaultEditors.put(boolean.class, new 
CustomBooleanEditor(false)); 

this.defaultEditors.put(Boolean.class, new 


CustomBooleanEditor(true)); 


// The JDK does not contain default editors for number wrapper 
types! 
// Override JDK primitive number editors with our own 
CustomNumberEditor. 
this.defaultEditors.put(byte.class, new 
CustomNumberEditor(Byte.class, false)); 
this.defaultEditors.put(Byte.class, new 
CustomNumberEditor(Byte.class, true)); 
this.defaultEditors.put(short.class, new 
CustomNumberEditor(Short.class, false)); 
this.defaultEditors.put(Short.class, new 
CustomNumberEditor(Short.class, true)); 
this.defaultEditors.put(int.class, new 
CustomNumberEditor(Integer.class, false)); 
this.defaultEditors.put(Integer.class, new 
CustomNumberEditor(Integer.class, true)); 
this.defaultEditors.put(long.class, new 
CustomNumberEditor(Long.class, false)); 
this.defaultEditors.put(Long.class, new 
CustomNumberEditor(Long.class, true)); 
this.defaultEditors.put(float.class, new 
CustomNumberEditor(Float.class, false)); 
this.defaultEditors.put(Float.class, new 
CustomNumberEditor(Float.class, true)); 
this.defaultEditors.put(double.class, new 
CustomNumberEditor(Double.class, false)); 


this.defaultEditors.put(Double.class, new 
CustomNumberEditor(Double.class, true)); 
this.defaultEditors.put(BigDecimal.class, new 
CustomNumberEditor(BigDecimal. 
class, true)); 
this.defaultEditors.put(BigInteger.class, new 
CustomNumberEditor(BigInteger. 
class, true)); 
// Only register config value editors if explicitly requested. 
if (this.config ValueEditorsActive) { 
String ArrayPropertyEditor sae = new 
String ArrayPropertyEditor(); 
this.defaultEditors.put(String[].class, sae); 
this.defaultEditors.put(short[].class, sae); 
this.defaultEditors.put(int[].class, sae); 
this.defaultEditors.put(long[].class, sae); 


} 

具体 的 调用 方法 我 们 就 不 去 深究 了 ， 但 是 至 少 通 过 这 个 方法 我 们 
已 经 知道 了 在 Spring 中 定义 了 上 面 一 系列 常用 的 属性 编辑 器 使 我 们 可 
以 方便 地 进行 配置 。 如 果 我 们 定义 的 bean 中 的 某 个 属性 的 类 型 不 在 上 
面 的 单 用 配置 中 的 话 ， 才 需要 我 们 进行 个 性 化 属性 编辑 器 的 注册 。 


6.5.3 添加 ApplicationContextAwareProcessor 处 理 器 


了 解 了 属性 编辑 器 的 使 用 后 ， 接 下 来 我 们 继续 通过 
AbstractApplicationContext 的 prepareBeanFactory 方法 的 主线 来 进行 函 
数 跟踪 。 对 于 beanFactory.addBeanPostProcessor(new 


ApplicationContextAwareProcessor(this)) 其 实 主要 目的 就 是 注册 个 
BneaPostProcessor， 而 真正 的 逻辑 还 是 在 
ApplicationContextAwareProcessor 中 。 
ApplicationContextAwareProcessor 实 现 BeanPostProcessor 接 口 ， 我 
们 回顾 下 之 前 讲 过 的 内 容 ， 在 bean 实 例 化 的 时 候 ， 也 就 是 Spring 激活 
bean 的 init-method 的 前 后 ， 会 调用 BeanPost Processor 的 
postProcessBeforeInitialization 方 法 和 postProcessAfterInitialization 方 法 。 
同样 ， 对 于 ApplicationContextAwareProcessor 我 们 也 关心 这 两 个 方法 。 
对 于 postProcessAfterInitialization 方 法 ， 在 
ApplicationContextAwareProcessor 中 并 没有 做 过 多 逻辑 处 理 。 
public Object postProcessAfterInitialization(Object bean, String 
beanName) 1 
return bean; 
} 
那么 ， 我 们 重点 看 一 下 postProcessBeforeInitialization 方 法 。 
public Object postProcessBeforeInitialization(final Object bean, String 
beanName) throws 
BeansException 1 
AccessControlContext acc - null; 
if (System.getSecurityManager() != null && 
(bean instanceof EnvironmentAware || bean instanceof 
EmbeddedValue 
ResolverAware || 
bean instanceof ResourceLoaderAware || bean instanceof 
ApplicationEventPublisherAware || 
bean instanceof MessageSourceAware || bean instanceof 


ApplicationContextAware)) 1 


acc = 
this.applicationContext.getBeanFactory().getA ccessControlContext(); 
i 
if (acc != null) { 


AccessController.doPrivileged(new PrivilegedAction<Object>() 


public Object run() { 
invokeAwarelnterfaces(bean); 


return null; 


} 
}, acc); 
} 
else { 


invokeAwarelnterfaces(bean); 
} 
return bean; 
} 
private void invokeAwareInterfaces(Object bean) 1 
if (bean instanceof Aware) 1 
if (bean instanceof EnvironmentAware) ( 
((EnvironmentAware) 
bean).setEnvironment(this.applicationContext. 
getEnvironment()); 
} 
if (bean instanceof EmbeddedValueResolverAware) { 
((EmbeddedValueResolverAware) 
bean).setEmbedded ValueResolver( 


new EmbeddedValueResolver(this.applicationContext. 
getBean 
Factory())); 
j 
if (bean instanceof ResourceLoaderAware) { 
((ResourceLoaderAware) 
bean).setResourceLoader(this.applicationContext); 
} 
if (bean instanceof ApplicationEventPublisherAware) { 
((ApplicationEventPublisherAware) 
bean).setApplicationEventPublisher 
(this.applicationContext); 
} 
if (bean instanceof MessageSourceAware) { 
((MessageSourceAware) 
bean).setMessageSource(this.applicationContext); 
} 
if (bean instanceof ApplicationContextAware) { 
((ApplicationContextAware) bean).setApplicationContext(this. 


applicationContext); 


} 

postProcessBeforelnitialization 方法 中 调用 了 
invokeAwareInterfaces。 从 invokeAwareInterfaces 方 法 中 ， 我 们 或 许 已 
经 或 多 或 少 了 解 了 Spring 的 用 意 ， 实 现 这 些 Aware 接 口 的 bean 在 被 初始 
化 之 后 ， 可 以 取得 一 些 对 应 的 资源 。 


6.5.4 SEZA 


4 Spring4 ApplicationContextAwareProcessor7tHHB[m, ABATE 
invokeAwareInterfaces 方 法 中 间接 调用 的 Aware 类 已 经 不 是 普通 的 bean 
了 ， 如 ResourceLoaderAware、ApplicationEventPublisher Aware 等 ， 那 
么 当然 需要 在 Spring 做 bean 的 依赖 注入 的 时 候 忽 略 它 们 。 而 
ignoreDependencyInterface 的 作用 正 是 在 此 。 

/设置 了 几 个 忽略 自动 装配 的 接口 


beanFactory.ignoreDependencyInterface(ResourceLoaderAware.class); 


beanFactory.ignoreDependencyInterface(ApplicationEventPublisherAware. 


class); 
beanFactory.ignoreDependencyInterface(MessageSourceAware.class); 


beanFactory.ignoreDependencyInterface(ApplicationContextAware.class); 


beanFactory.ignoreDependencyInterface(EnvironmentAware.class); 


Spring 中 有 了 忽略 依赖 的 功能 ， 当 然 也 必 不 可 少 地 会 有 注册 依赖 
的 功能 AEo 
beanFactory.registerResolvableDependency(BeanFactory.class, 
beanFactory); 
beanFactory.registerResolvableDependency(ResourceLoader.class, 
this); 


beanFactory.registerResolvableDependency(ApplicationEventPublisher.clas 


s, this); 


beanFactory.registerResolvableDependency(A pplicationContext.class, 
this); 

当 注 册 了 依赖 解析 后 ， 例 如 当 注 册 了 对 BeanFactory.class 的 解析 依 
赖 后 ， 当 bean 的 属性 注入 的 时 候 ， 一 旦 检测 到 属性 为 BeanFactory 类 型 
便 会 将 beanFactory 的 实例 注入 进去 。 


6.6 BeanFactory 的 后 处 理 


BeanFacotry 作 为 Spring 中 容器 功能 的 基础 ， 用 于 存放 所 有 已 经 加 
载 的 bean， 为 了 保证 程序 上 的 高 可 扩展 性 ，Spring 针对 BeanFactory 做 
了 大 量 的 扩展 ， 比 如 我 们 熟知 的 PostProcessor 等 都 是 在 这 里 实现 的 。 


6.6.1 激活 注册 的 BeanFactoryPostProcessor 


正式 开始 介绍 之 前 我 们 先 了 解 下 BeanFactoryPostProcessor 的 用 
Bo 

BeanFactoryPostProcessor 接 口 跟 BeanPostProcessor 类 似 ， 可 以 对 
bean 的 定义 (配置 元 数据 ) 进行 处 理 。 也 就 是 说 ，Spring IoC 容 器 允许 
BeanFactoryPostProcessor 在 容器 实际 实例 化 任何 其 他 的 bean 之 前 读 取 
配置 元 数据 ， 并 有 可 能 修改 它 。 如 果 你 愿意 ， 你 可 以 配置 多 个 
BeanFactoryPostProcessor。 你 还 能 通过 设置 “order” 属 性 来 控制 
BeanFactoryPostProcessor 的 执行 次 序 〈 仅 当 BeanFactoryPostProcessor 
实现 了 Ordered 接口 时 你 才 可 以 设置 此 属性 ， 因 此 在 实现 
BeanFactoryPostProcessor 时 ， 就 应 当 考 虑 实现 Ordered 接口 ) 。 请 参 
# BeanFactoryPostProcessor 和 Ordered 接 口 的 JavaDoc 以 获取 更 详细 的 
信息 。 


如 果 你 想 改 变 实际 的 bean 实例 (例如 从 配置 元 数据 创建 的 对 
R) ， 那 么 你 最 好 使 用 BeanPostProcessor。 同样 地 ， 
BeanFactoryPostProcessor 的 作用 域 范 围 是 容器 级 的 。 它 只 和 你 所 使 用 
的 容器 有 关 。 如 果 你 在 容器 中 定义 一 个 BeanFactoryPostProcessor, È 
仅仅 对 此 容器 中 的 bean 进 行 后 置 处 理 。BeanFactoryPostProcessor 不 会 
对 定义 在 另 一 个 容器 中 的 bean 进 行 后 置 处 理 ， 即 使 这 两 个 容器 都 是 在 
同一 层次 上 。 在 Spring 中 存在 对 于 BeanFactoryPostProcessor 的 典型 应 
用 ， 比 如 PropertyPlaceholderConfigurer。 

1。BeanFactoryPostProcessor 的 典型 应 用 
PropertyPlaceholderConfigurer 

有 时 候 ， 阅 读 Spring 的 Bean 摘 述 文件 时 ， 你 也 许 会 遇 到 类 似 如 下 
的 一 些 配置 : 

<bean id-"message" class="distConfig.HelloMessage"> 

<property name="mes"> 
<value>${bean.message}</value> 
</property> 

</bean> 

其 中 竟然 出 现 了 变量 引用 : ${bean.message}。 这 就 是 Spring 的 分 
散 配 置 ， 可 以 在 另外 的 配置 文件 中 为 bean.message 指 定 值 。 如 在 
bean.property 配 置 如 下 定义 : 

bean.message-Hi,can you find me? 

当 访 问 名 为 message 的 bean 时 ，mes 属 性 就 会 被 置 为 字符 串 “ Hi,can 
you find me?”， 但 Spring 框架 是 怎么 知道 存在 这 样 的 配置 文件 呢 ? 这 就 
要 靠 PropertyPlaceholderConfigurer 这 个 类 的 bean: 

<bean id="mesHandler" 
class="org.Springframework.beans.factory.config. Property Placeholder 


Configurer"> 


«property name="locations"> 
<list> 
<value>config/bean.properties</value> 
</list> 
</property> 

</bean> 

在 这 个 bean 中 指定 了 配置 文件 为 config/bean.properties。 到 这 里 似 
乎 找到 问题 的 答案 了 ， 但 是 其 实 还 有 个 问题 。 这 个 “mesHandler” 只 不 
过 是 Spring 框架 管理 的 一 个 bean， 并 没有 被 别 的 bean 或 者 对 象 引 用 ， 
Spring 的 beanFactory 是 怎么 知道 要 从 这 个 bean 中 获取 配置 信息 的 呢 ? 

查看 层级 结构 可 以 看 出 PropertyPlaceholderConfigurer 这 个 类 间接 
继承 了 BeanFactory PostProcessor 接 口 。 这 是 一 个 很 特别 的 接口 ， 当 
Spring 加 载 任何 实现 了 这 个 接口 的 bean 的 配置 时 ， 都 会 在 bean 工厂 载 
入 所 有 bean 的 配置 之 后 执行 postProcessBeanFactory 方法 。 在 
PropertyResourceConfigurer 类 中 实现 了 postProcessBeanFactory 方法 ， 
在 方法 中 先后 调用 了 mergeProperties、 convertProperties, 
processProperties 这 3 个 方法 ， 分 别 得 到 配置 ， 将 得 到 的 配置 转换 为 合 
适 的 类 型 ， 最 后 将 配置 内 容 告知 BeanFactory。 

正 是 通过 实现 BeanFactoryPostProcessor 接 口 ，BeanFactory 会 在 实 
例 化 任何 bean 之 前 获得 配置 信息 ， 从 而 能 够 正确 解析 bean 描 述 文 件 中 
的 变量 引用 。 

2。 使 用 自 定义 BeanFactoryPostProcessor 

我 们 以 实现 一 个 BeanFactoryPostProcessor， 去 除 潜 在 的 “流氓 ” 属 
性 值 的 功能 来 展示 自 定 义 BeanFactoryPostProcessor 的 创建 及 使 用 ， 例 
如 bean 定 义 中 留 下 bollocks 这 样 的 字眼 。 

配置 文件 BeanFactory.xml 


<?xml version="1.0" encoding="UTF-8"?> 


«beans xmlns-"http://www.Springframework.org/schema/beans" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="http://www.Springframework.org/schema/beans 
http://www.Springframework.org/schema/beans/Spring-beans.xsd 
"> 
<bean id-"bfpp" 
class="com.Spring.ch04.ObscenityRemovingBeanFactoryPostProcessor"> 
<property name="obscenties"> 
<set> 
<value>bollocks</value> 
<value>winky</value> 
<value>bum</value> 
<value>Microsoft</value> 
</set> 
</property> 
</bean> 
<bean id="simpleBean" 
class="com.Spring.ch04.SimplePostProcessor"> 
<property name="connectionString" value="bollocks"/> 
<property name-"password" value="imaginecup"/> 
<property name-"username" value="Microsoft"/> 
</bean> 
</beans> 
Obscenity RemovingBeanFactoryPostProcessor.java 
public class ObscenityRemovingBeanFactoryPostProcessor 
implements 


BeanFactoryPostProcessor { 


private Set<String> obscenties; 
public ObscenityRemovingBeanFactoryPostProcessor(){ 
this.obscenties=new HashSet<String>(); 
} 
public void postProcessBeanFactory( 
ConfigurableListableBeanFactory beanFactory) throws 
BeansException { 
String[] beanNames=beanFactory.getBeanDefinitionNames(); 
for(String beanName:beanNames){ 
BeanDefinition 
bd=beanFactory.getBeanDefinition(beanName); 
String ValueResolver valueResover=new 
String ValueResolver() { 
public String resolveString Value(String strVal) { 
if(isObscene(strVal)) return "*****"; 
return str Val; 
j 
F 
BeanDefinitionVisitor visitor=new 
BeanDefinitionVisitor(valueResover); 


visitor.visitBeanDefinition(bd); 


i 
public boolean isObscene(Object value){ 
String potentialObscenity=value.toString().toUpperCase(); 


return this.obscenties.contains(potentialObscenity); 


public void setObscenties(Set<String> obscenties) 1 
this.obscenties.clear(); 
for(String obscenity:obscenties) { 


this.obscenties.add(obscenity.toUpperCase()); 


} 
执行 类 : 
public class PropertyConfigurerDemo { 
public static void main(String[] args) 1 
ConfigurableListableBeanFactory bf=new XmlBeanFactory(new 
ClassPathResource 
("/META-INF/BeanFactory.xml")); 
BeanFactoryPostProcessor bfpp- 
(BeanFactoryPostProcessor)bf.getBean("bfpp"); 
bfpp.postProcessBeanFactory(bf); 
System.out.printIn(bf.getBean(" simpleBean")); 


} 

输出 结果 : 

SimplePostProcessor{connectionString=***** username=***** pass 
word=imaginecup 

ji: ObscenityRemovingBeanFactoryPostProcessor Spring 很 好 地 实 
现 了 屏 焙 掉 obscenties 定 义 的 不 应 该 展示 的 属性 。 

3。 激 活 BeanFactoryPostProcessor 

了 解 了 BeanFactoryPostProcessor 的 用 法 后 便 可 以 深入 研究 
BeanFactoryPostProcessor 的 调用 过 程 了 。 


protected void 
invokeBeanFactoryPostProcessors(ConfigurableListableBeanFactory 
beanFactory) 1 
// Invoke BeanDefinitionRegistryPostProcessors first, if any. 
Set<String> processedBeans = new HashSet<String>(); 
/对 BeanDefinitionRegistry 类 型 的 处 理 
if (beanFactory instanceof BeanDefinitionRegistry) { 

BeanDefinitionRegistry registry = (BeanDefinitionRegistry) 
beanFactory; 

List<BeanFactoryPostProcessor> regularPostProcessors = new 
LinkedList<BeanFactoryPostProcessor>(); 

[e 
* BeanDefinitionRegistryPostProcessor 
*/ 

List<BeanDefinitionRegistryPostProcessor> 
registryPostProcessors = 
new&nbsp;LinkedList<BeanDefinitionRegistryPostProcessor>(); 

/二 
* 便 编 码 注 册 的 后 处 理 器 
zr 

for (BeanFactoryPostProcessor postProcessor : 
getBeanFactoryPostProcessors()) 1 

if (postProcessor instanceof 
BeanDefinitionRegistryPostProcessor) 1 
BeanDefinitionRegistryPostProcessor registryPostProcessor 


-(Bean DefinitionRegistryPostProcessor) postProcessor; 


/对 于 BeanDefinitionRegistryPostProcessor 类 型 ， 在 
BeanFactoryPostProcessor 的 基础 上 还 有 自己 定义 的 方法 ， 需 要 先 调 用 


registryPostProcessor.postProcessBeanDefinitionRegistry(registry); 
registryPostProcessors.add(registryPostProcessor); 
jelse 1 
// 记 录 常 规 BeanFactoryPostProcessor 


regularPostProcessors.add(postProcessor); 


* 配置 注册 的 后 处 理 器 
g 
Map<String, BeanDefinitionRegistryPostProcessor> beanMap = 
beanFactory. 
getBeansOfType(BeanDefinitionRegistryPostProcessor.class, 
true, false); 
List<BeanDefinitionRegistryPostProcessor> 
registryPostProcessorBeans = 
new ArrayList<BeanDefinitionRegistryPostProcessor> 
(beanMap.values()); 
OrderComparator.sort(registry PostProcessorBeans); 
for (BeanDefinitionRegistryPostProcessor postProcessor : 
registryPostProcessorBeans) 1 
/BeanDefinitionRegistryPostProcessor 的 特殊 处 理 


postProcessor.postProcessBeanDefinitionRegistry(registry); 


/激活 postProcessBeanFactory 方 法 ， 之 前 激活 的 是 
postProcessBeanDefinitionRegistry 
// 硬 编码 设置 的 BeanDefinitionRegistryPostProcessor 
invokeBeanFactoryPostProcessors(registry PostProcessors, 
beanFactory); 
/配置 的 BeanDefinitionRegistryPostProcessor 
invokeBeanFactoryPostProcessors(registryPostProcessorBeans, 
beanFactory); 
// 常 规 BeanFactoryPostProcessor 
invokeBeanFactoryPostProcessors(regularPostProcessors, 
beanFactory); 
processedBeans.addAll(beanMap.keySet()); 
j 
else { 


// Invoke factory processors registered with the context instance. 


invokeBeanFactory PostProcessors(getBeanFactory PostProcessors(), 
beanFactory); 

i 

/对 于 配置 中 读 取 的 BeanFactoryPostProcessor 的 处 理 

String[] postProcessorNames = 
beanFactory.getBeanNamesForType(BeanFactoryPost 

Processor.class, true, false); 

List<BeanFactoryPostProcessor> priorityOrderedPostProcessors = 
new ArrayList 


<BeanFactoryPostProcessor>(); 


List<String> orderedPostProcessorNames = new ArrayList<String> 
0; 
List<String> nonOrderedPostProcessorNames = new 
ArrayList<String>(); 
// 对 后 处 理 器 进行 分 类 
for (String ppName : postProcessorNames) { 
if (processedBeans.contains(ppName)) { 
// 已 经 处 理 过 
}else if (isTypeMatch(ppName, PriorityOrdered.class)) { 


priorityOrderedPostProcessors.add(beanFactory.getBean(ppName, 
BeanFactoryPostProcessor.class)); 
yelse if (isTypeMatch(ppName, Ordered.class)) { 
orderedPostProcessorNames.add(ppName); 
jelse { 


nonOrderedPostProcessorNames.add(ppName); 


} 

/按照 优先 级 进行 排序 

OrderComparator.sort(priorityOrderedPostProcessors); 

invokeBeanFactory PostProcessors(priorityOrderedPostProcessors, 
beanFactory); 

// Next, invoke the BeanFactoryPostProcessors that implement 
Ordered. 

List<BeanFactoryPostProcessor> orderedPostProcessors = new 
ArrayList<BeanFactory 


PostProcessor>(); 


for (String postProcessorName : orderedPostProcessorNames) 1 
orderedPostProcessors.add(getBean(postProcessorName, 
BeanFactory PostProcessor. 
class)); 
} 
/按照 order 排 序 
OrderComparator.sort(orderedPostProcessors); 
invokeBeanFactory PostProcessors(orderedPostProcessors, 
beanFactory); 
/无 序 ， 直 接 调用 
List<BeanFactoryPostProcessor> nonOrderedPostProcessors = new 
ArrayList<BeanFactory 
PostProcessor>(); 


for (String postProcessorName : nonOrderedPostProcessorNames) 


{ 
nonOrderedPostProcessors.add(getBean(postProcessorName, 
BeanFactoryPostProcessor.class)); 
} 
invokeBeanFactoryPostProcessors(nonOrderedPostProcessors, 
beanFactory); 


} 

从 上 面 的 方法 中 我 们 看 到 ， 对 于 BeanFactoryPostProcessor 的 处 理 
主要 分 两 种 情况 进行 ， 一 个 是 对 于 BeanDefinitionRegistry 类 的 特殊 处 
理 ， 另 一 种 是 对 普通 的 BeanFactoryPostProcessor 进 行 处 理 。 而 对 于 每 
种 情况 都 需要 考虑 硬 编 码 注入 注册 的 后 处 理 器 以 及 通过 配置 注入 的 后 
处 理 器 。 


对 于 BeanDefinitionRegistry 类 型 的 处 理 类 的 处 理 主要 包括 以 下 内 
合 。 

(1) 对 于 硬 编码 注册 的 后 处 理 器 的 处 理 ， 主 要 是 通过 
AbstractApplicationContext 中 的 添加 处 理 器 方法 
addBeanFactoryPostProcessor 进 行 添 加 。 

public void addBeanFactoryPostProcessor(BeanFactoryPostProcessor 
beanFactoryPostProcessor) { 
this.beanFactoryPostProcessors.add(beanFactoryPostProcessor); 
} 
添加 后 的 后 处 理 器 会 存放 在 beanFactoryPostProcessors 中 ， 而 在 处 
理 BeanFactoryPostProcessor 时 候 会 首先 检测 beanFactoryPostProcessors 
是 否 有 数据 。 当 然 ，BeanDefinitionRegistryPostProcessor 继 承 自 
BeanFactoryPostProcessor， 不 但 有 BeanFactoryPostProcessor 的 特性 ， 同 
时 还 有 自己 定义 的 个 性 化 方法 ， 也 需要 在 此 调用 。 所 以 ， 这 里 需要 从 
beanFactoryPostProcessors 中 挑 出 BeanDefinitionRegistryPostProcessor 的 
后 处 理 器 ， 并 进行 其 postProcessBeanDefinitionRegistry 方 法 的 激活 。 
(2) 记录 后 处 理 器 主要 使 用 了 三 个 List 完 成 。 
registryPostProcessors: 记录 通过 硬 编码 方式 注册 的 
BeanDefinitionRegistryPostProcessor 类 型 的 处 理 器 。 
regularPostProcessors: 记录 通过 硬 编码 方式 注册 的 
BeanFactoryPostProcessor 类 型 的 处 理 器 。 
registryPostProcessorBeans: 记录 通过 配置 方式 注册 的 
BeanDefinitionRegistryPostProcessor 类 型 的 处 理 器 。 

(3) 对 以 上 所 记录 的 List 中 的 后 处 理 器 进行 统一 调用 
BeanFactoryPostProcessor 的 postProcessBeanFactory 方 法 。 

(4) 对 beanFactoryPostProcessors 中 非 
BeanDefinitionRegistryPostProcessor 类 型 的 后 处 理 器 进行 统一 的 


BeanFactoryPostProcessor 的 postProcessBeanFactory 方 法 调用 。 
(5) 普通 beanFactory 处 理 。 

BeanDefinitionRegistryPostProcessor 只 对 BeanDefinitionRegistry 类 
型 的 ConfigurableListable BeanFactory 有 有效， 所 以 如 果 判 断 所 示 的 
beanFactory 并 不 是 BeanDefinitionRegistry， 那 么 便 可 以 忽略 
BeanDefinitionRegistryPostProcessor， 而 直接 处 理 
BeanFactoryPostProcessor， 当 然 获取 的 方式 与 上 面 的 获取 类 似 。 

这 里 需要 提 到 的 是 ， 对 于 硬 编 码 方式 手动 添加 的 后 处 理 器 是 不 需 
要 做 任何 排序 的 ， 但 是 在 配置 文件 中 读 取 的 处 理 器 ，Sping 并 不 保证 
读 取 的 顺序 。 所 以 ， 为 了 保证 用 户 的 调用 顺序 的 要 求 ，Spring 对 于 后 
处 理 器 的 调用 支持 按照 PriorityOrdered 或 者 Ordered 的 顺序 调用 。 


6.6.2 7 BeanPostProcessor 


上 文中 提 到 了 BeanFacotoryPostProcessors 的 调用 ， 现 在 我 们 来 探 
索 下 BeanPostProcessor， 但 是 这 里 并 不 是 调用 ， 而 是 注册 。 真 正 的 调 
用 其 实 是 在 bean 的 实例 化 阶段 进行 的 。 这 是 一 个 很 重要 的 步骤 ， 也 是 
很 多 功能 BeanFactory 不 支持 的 重要 原因 。Spring 中 大 部 分 功能 都 是 通 
过 后 处 理 器 的 方式 进行 扩展 的 ， 这 是 Spring 框 架 的 一 个 特性 ， 但 是 在 
BeanFactory 中 其 实 并 没有 实现 后 处 理 器 的 自动 注册 ， 所 以 在 调用 的 时 
候 如 果 没 有 进行 手动 注册 其 实 是 不 能 使 用 的 。 但 是 在 
ApplicationContext 中 却 添 加 了 目 动 注册 功能 ， 如 目 定 义 这 样 一 个 后 处 
Pas: 

public class MyInstantiationAwareBeanPostProcessor implements 
InstantiationAwareBean 

PostProcessor{ 

public Object postProcessBeforelnitialization(Object bean, String 


beanName) 


throws BeansException 1 
System.out.printIn("===="); 


return null; 


在 配置 文件 中 添加 配置 : 
<bean class="processors.MyInstantiationAwareBeanPostProcessor"/> 
那么 使 用 BeanFactory 方式 进行 Spring 的 bean 的 加 载 时 是 不 会 
任何 改变 的 ， 但 是 使 用 ApplicationContext 方 式 获 取 bean 的 时 候 会 在 获 
取 每 个 bean 时 打印 出 “====”， 而 这 个 特性 就 是 在 
registerBeanPostProcessors 方 法 中 完成 的 。 
我 们 继续 探索 registerBeanPostProcessors 的 方法 实现 。 
protected void 
registerBeanPostProcessors(ConfigurableListableBeanFactory beanFactory) 
{ 
String[] postProcessorNames = 
beanFactory.getBeanNamesForType(BeanPostProcessor.class, 
true, false); 
/* 
* BeanPostProcessorChecker 是 一 个 普通 的 信息 打印 ， 可 能 会 
有 些 情况 ， 
* 当 Spring 的 配置 中 的 后 处 理 器 还 没有 被 注册 就 已 经 开始 了 
bean 的 初始 化 时 
* 便 会 打印 出 BeanPostProcessorChecker 中 设 定 的 信息 
*/ 


int beanProcessorTargetCount = 
beanFactory.getBeanPostProcessorCount() + 1 + 

postProcessorNames.length; 

beanFactory.addBeanPostProcessor(new 
BeanPostProcessorChecker(beanFactory, 

beanProcessorTargetCount)); 

/使 用 PriorityOrdered 保 证 顺序 

List<BeanPostProcessor> priorityOrderedPostProcessors = new 
ArrayList<Bean 

PostProcessor>(); 

//MergedBeanDefinitionPostProcessor 

List<BeanPostProcessor> internalPostProcessors = new 
ArrayList<BeanPost 

Processor>(); 

/使 用 Ordered 保 证 顺序 


List<String> orderedPostProcessorNames = new ArrayList<String> 


0; 

/无 序 BeanPostProcessor 

List<String> nonOrderedPostProcessorNames = new 
ArrayList<String>(); 


for (String ppName : postProcessorNames) { 
if (isTypeMatch(ppName, PriorityOrdered.class)) { 
BeanPostProcessor pp = beanFactory.getBean(ppName, 
BeanPostProcessor.class); 
priorityOrderedPostProcessors.add(pp); 
if (pp instanceof MergedBeanDefinitionPostProcessor) { 


internalPostProcessors.add(pp); 


j 
Jelse if (isTypeMatch(ppName, Ordered.class)) { 
orderedPostProcessorNames.add(ppName); 
jelse 1 


nonOrderedPostProcessorNames.add(ppName); 


j 
/第 一 步 ， 注 册 所 有 实现 PriorityOrdered 的 BeanPostProcessor 
OrderComparator.sort(priorityOrderedPostProcessors); 
registerBeanPostProcessors(beanFactory, 
priorityOrderedPostProcessors); 
/第 二 步 ， 注 册 所 有 实现 Ordered 的 BeanPostProcessor 
List<BeanPostProcessor> orderedPostProcessors = new 
ArrayList<BeanPostProcessor>(); 
for (String ppName : orderedPostProcessorNames) { 
BeanPostProcessor pp = beanFactory.getBean(ppName, 
BeanPostProcessor.class); 
orderedPostProcessors.add(pp); 
if (pp instanceof MergedBeanDefinitionPostProcessor) { 


internalPostProcessors.add(pp); 


} 

OrderComparator.sort(orderedPostProcessors); 
registerBeanPostProcessors(beanFactory, orderedPostProcessors); 
/第 三 步 ， 注 册 所 有 无 序 的 BeanPostProcessor 
List<BeanPostProcessor> nonOrderedPostProcessors = new 


ArrayList<BeanPostProcessor>(); 


for (String ppName : nonOrderedPostProcessorNames) 1 
BeanPostProcessor pp = beanFactory.getBean(ppName, 
BeanPostProcessor.class); 
nonOrderedPostProcessors.add(pp); 
if (pp instanceof MergedBeanDefinitionPostProcessor) 1 


internalPostProcessors.add(pp); 


j 
registerBeanPostProcessors(beanFactory, 
nonOrderedPostProcessors); 
/第 四 步 ， 注 册 所 有 MergedBeanDefinitionPostProcessor 类 型 的 
BeanPostProcessor, #4F 
重复 注册 ， 
/在 beanFactory.addBeanPostProcessor 中 会 先 移 除 已 经 存在 的 
BeanPostProcessor 
OrderComparator.sort(internal PostProcessors); 
registerBeanPostProcessors(beanFactory, internalPostProcessors); 
/添加 ApplicationListener 探 测 器 
beanFactory.addBeanPostProcessor(new 
ApplicationListenerDetector()); 
j 
配合 源码 以 及 注释 ， 在 registerBeanPostProcessors 方法 中 所 做 的 
逻辑 相信 大 家 已 经 很 清楚 了 ， 我 们 再 做 一 下 总 结 。 
首先 我 们 会 发 现 ， 对 于 BeanPostProcessor 的 处 理 与 
BeanFactoryPostProcessor 的 处 理 极为 相似 ， 但 是 似乎 又 有 些 不 一 样 的 
地 方 。 经 过 反复 的 对 比 发 现 ， 对 于 BeanFactoryPostProcessor 的 处 理 要 
区 分 两 种 情况 ， 一 种 方式 是 通过 硬 编码 方式 的 处 理 ， 另 一 种 是 通过 配 


置 文件 方式 的 处 理 。 那 么 为 什么 在 BeanPostProcessor 的 处 理 中 只 考虑 
了 配置 文件 的 方式 而 不 考虑 硬 编码 的 方式 呢 ? 提出 这 个 问题 ， 还 是 因 
为 读者 没有 完全 理解 两 者 实现 的 功能 。 对 于 BeanFactoryPostProcessor 
的 处 理 ， 不 但 要 实现 注册 功能 ， 而 且 还 要 实现 对 后 处 理 器 的 激活 操 
作 ， 所 以 需要 载 入 配置 中 的 定义 ， 并 进行 激活 ， 而 对 于 
BeanPostProcessor 并 不 需要 马上 调用 ， 再 说 ， 硬 编码 的 方式 实现 的 功 
能 是 将 后 处 理 器 提取 并 调用 ， 这 里 并 不 需要 调用 ， 当 然 不 需要 考虑 硬 
编码 的 方式 了 ， 这 里 的 功能 只 需要 将 配置 文件 的 BeanPostProcessor 提 
取出 来 并 注册 进入 beanFactory 就 可 以 了 。 
对 于 beanFactory 的 注册 ， 也 不 是 直接 注册 就 可 以 的 。 在 Spring 
中 支持 对 于 BeanPost Processor 的 排序 ， 比 如 根据 PriorityOrdered 进 行 排 
序 、 根 据 Ordered 进 行 排序 或 者 无 序 ， 而 Spring 在 BeanPostProcessor 的 
激活 顺序 的 时 候 也 会 考虑 对 于 顺序 的 问题 而 先进 行 排序 。 
这 里 可 能 有 个 地 方 读 者 不 是 很 理解 ， 对 于 internalPostProcessors 
中 存储 的 后 处 理 器 也 就 是 MergedBeanDefinitionPostProcessor 类 型 的 处 
理 器 ， 在 代码 中 似乎 是 被 重复 调用 了 ， 如 : 
for (String ppName : postProcessorNames) { 
if (isTypeMatch(ppName, PriorityOrdered.class)) { 
BeanPostProcessor pp = beanFactory.getBean(ppName, 
BeanPostProcessor.class); 
priorityOrderedPostProcessors.add(pp); 
if (pp instanceof MergedBeanDefinitionPostProcessor) 1 
internalPostProcessors.add(pp); 
j 
yelse if (isTypeMatch(ppName, Ordered.class)) 1 
orderedPostProcessorNames.add(ppName); 
jelse 1 


nonOrderedPostProcessorNames.add(ppName); 


-m 


其 实 不 是 ， 我 们 可 以 看 看 对 于 registerBeanPostProcessors 方 法 的 实 
现 方式 。 
private void registerBeanPostProcessors( 
ConfigurableListableBeanFactory beanFactory, 
List<BeanPostProcessor> 
postProcessors) { 
for (BeanPostProcessor postProcessor : postProcessors) { 


beanFactory.addBeanPostProcessor(postProcessor); 


} 
public void addBeanPostProcessor(BeanPostProcessor 
beanPostProcessor) 1 
Assert.notNull(beanPostProcessor, "BeanPostProcessor must not be 
null"); 
this.beanPostProcessors.remove(beanPostProcessor); 
this.beanPostProcessors.add(beanPostProcessor); 
if (beanPostProcessor instanceof 
InstantiationAwareBeanPostProcessor) 1 
this.hasInstantiationAwareBeanPostProcessors - true; 
l 
if (beanPostProcessor instanceof 
DestructionAwareBeanPostProcessor) { 


this.hasDestructionAwareBeanPostProcessors - true; 


} 
可 以 看 到 ， 在 registerBeanPostProcessors 方法 的 实现 中 其 实 已 经 


确保 了 beanPostProcessor 的 唯一 性 ， 个 人 猜想 ， 之 所 以 选择 在 
registerBeanPostProcessors 中 没有 进行 重复 移 除 操作 或 许 是 为 了 保持 分 
类 的 效果 ， 使 逻辑 更 为 清晰 吧 。 


6.6.3 初始 化 消息 资源 
在 进行 这 段 图 数 的 解析 之 前 ， 我 们 同样 先 来 回顾 Spring 国际 化 的 
使 用 方法 。 


假设 我 们 正在 开发 一 个 支持 多 国语 言 的 Web 应 用 程序 ， 要 求 系统 
能 够 根据 客户 端的 系统 的 语言 类 型 返回 对 应 的 界面 : 英文 的 操作 系统 
返回 英文 界面 ， 而 中 文 的 操作 系统 则 返回 中 文 界 面 一 一 这 便 是 典型 的 
i18n 国 际 化 问题 。 对 于 有 国际 化 要 求 的 应 用 系统 ， 我 们 不 能 简单 地 采 
用 硬 编码 的 方式 编写 用 户 界 面 信息 、 报 错 信 息 等 内 容 ， 而 必须 为 这 些 
需要 国际 化 的 信息 进行 特殊 处 理 。 简 单 来 说 ， 就 是 为 每 种 语言 提供 一 
套 相 应 的 资源 文件 ， 并 以 规范 化 命名 的 方式 保存 在 特定 的 目录 中 ， 由 
系统 自动 根据 客户 端 语言 选择 适合 的 资源 文件 。 

“国际 化 信息 ”也 称 为 “本 地 化 信息 ”， 一 般 需要 两 个 条 件 才 可 以 确 
定 一 个 特定 类 型 的 本 地 化 信息 ， 它 们 分 别 是 “语言 类 型 * 和 “国家 /地 区 
的 类 型 "。 如 中 文本 地 化 信息 既 有 中 国 大 陆地 区 的 中 文 ， 又 有 中 国人 台湾 
地 区 、 中 国 香港 地 区 的 中 文 ， 还 有 新 加 坡地 区 的 中 文 。Java 通过 
java.util.Locale 类 表示 一 个 本 地 化 对 象 ， 它 允许 通过 语言 参数 和 国家 /地 
区 参数 创建 一 个 确定 的 本 地 化 对 象 。 

java.util.Locale 是 表示 语言 和 国家 /地 区 信息 的 本 地 化 类 ， 它 是 创建 
国际 化 应 用 的 基础 。 下 面 给 出 几 个 创建 本 地 化 对 象 的 示例 : 

10 带 有 语言 和 国家 /地 区 信息 的 本 地 化 对 象 


Locale locale1 = new Locale("zh","CN"); 

/2 只 有 语言 信息 的 本 地 化 对 象 

Locale locale2 = new Locale("zh"); 

/K3) 等 同 于 Locale("zh","CN") 

Locale locale3 = Locale.CHINA: 

/K&) 等 同 于 Locale("zh") 

Locale locale4 = Locale. CHINESE; 

/G) 获取 本 地 系统 默认 的 本 地 化 对 象 

Locale locale 5= Locale.getDefault(); 

JDK 的 java.util 包 中 提供 了 几 个 支持 本 地 化 的 格式 化 操作 工具 
类 : NumberFormat、DateFormat、MessageFormat， 而 在 woes 中 的 国 
际 化 资源 操作 也 无 非 是 对 于 这 些 类 的 封装 操作 ， 我 们 仅仅 介绍 
MessageFormat 的 用 法 以 帮助 大 家 回顾 : 

/信息 格式 化 串 

String pattern] = "{0}， 你 好 ! 你 于 {1} 在 工 丙 银行 趣 入 {2} To "; 

String pattern2 = "At {1,time,short} On{1,date,long}, {0} paid 
{2,number, currency }."; 

/用 于 动态 替换 占 位 符 的 参数 

Object[] params = {"John", new 
GregorianCalendar().getTime(),1.0E3}; 

/3) 使 用 默认 本 地 化 对 象 格式 化 信息 

String msg1 = MessageFormat.format(pattern1,params); 

NOFA EEE S TR EC TUTES 

MessageFormat mf - new MessageFormat(pattern2,Locale.US); 

String msg2 = mf.format(params); 

System.out.printIn(msg1); 

System.out.printIn(msg2); 


Spring 定义 了 访问 国际 化 信息 的 MessageSource 接口 ， 并 提供 了 
几 个 易 用 的 实现 类 。MessageSource 分 别 被 HierarchicalMessageSource 和 
ApplicationContext 接 口 扩 展 ， 这 里 我 们 主要 看 一 下 
HierarchicalMessageSource 接 口 的 几 个 实现 类 ， 如 图 6-3 所 示 。 


Al «Java Class» al «Java Class» al «Java Class» 


© ReloadableResourceB undieMessageSource © ResourceBundleMessageSource © Static MessageSource 
a AL 
"S iri 
习 «Java Class» 2 «Java Class» 
(3 DelegatingMessageSource © AbstractMessageSource 
四 a) 


al «Java Interface» 
© HierarchicalMessageSource 


A «Java Interface» 
© MessageSource 


图 6-3 MessageSource 类 图 结构 


HierarchicalMessageSource 接口 最 重要 的 两 个 实现 类 是 
ResourceBundleMessageSource 和 
ReloadableResourceBundleMessageSource。 它们 基于 Java 的 
ResourceBundle 基 础 类 实现 ， 允 许 仅 通过 资源 名 加 载 国际 化 资源 
ReloadableResourceBundleMessageSource 提 供 了 定时 刷新 功能 ， mm 
不 重启 系统 的 情况 下 ， 更 新 资源 的 信息 。 B oem 
于 程序 测试 ， 它 允许 通过 编程 的 方式 提供 国际 化 信息 。 


DelegatingMessageSource 是 为 方便 操作 父 MessageSource 而 提供 的 代理 
类 。 仅 仅 举 例 ResourceBundleMessageSource 的 实现 方式 。 
(1) 定义 资源 文件 。 
messages.properties (默认 : EX) ， 内 容 仅 一 句 ， 如 下 : 
test-test 
messages zh CN.properties (简体 中 文 ) 
test= 测 试 
然后 cmd， 打 开 命 令 行 窗口 ， 输 入 native2ascii -encoding gbk 
C:\messages_zh_CN.properties C:messages zh CN. tem.properties ,并 
将 C:messages zh CN. tem.properties 中 的 内 容 蔡 换 到 
messages_zh_CN.properties 中 ， 这 样 messages_zh_CN.properties 文件 就 
存放 的 是 转 码 后 的 内 容 了 ， 比 较 简单 。 
(2) 定义 配置 文件 。 
<bean id="messageSource" 
class="org.Springframework.context.support.ResourceBundleMessageSour 
Ce > 
<property name="basenames"> 
<list> 
<value>test/messages</value> 
</list> 
</property> 
</bean> 
其 中 ， 这 个 Bean 的 ID 必须 命名 为 messageSource， 否 则 会 抛 出 
NoSuchMessageException F $8 o 
(3) 使 用 。 通 过 ApplicationContext 访 问 国际 化 信息 。 


String[] configs = {"applicationContext.xml"}; 


ApplicationContext ctx = new 
ClassPathXmlApplicationContext(configs); 

/GD 直接 通过 容器 访问 国际 化 信息 

Object[] params = {"John", new GregorianCalendar().getTime() }; 

String str1 = ctx.getMessage( test" ,params,Locale.US); 

String str2 = ctx.getMessage("test",params,Locale.CHINA); 

System.out.println(str1); 

System.out.println(str2); 

了 解 了 Spring 国际 化 的 使 用 后 便 可 以 进行 源码 的 分 析 了 。 

在 initMessageSource 中 的 方法 主要 功能 是 提取 配置 中 定义 的 
messageSource， 并 将 其 记录 在 Spring 的 容器 中 ， 也 就 是 
AbstractApplicationContext 中 。 当 然 ， 如 果 用 户 未 设置 资源 文件 的 话 ， 
Spring 中 也 提供 了 默认 的 配置 DelegatingMessageSourceo 

在 initMessageSource 中 获取 自 定 义 资源 文件 的 方式 为 
beanFactory.getBean(MESSAGE_ SOURCE BEAN NAME, 
Hence class)， 在 这 里 Spring 使 用 了 硬 编码 的 方式 硬性 规定 了 子 

义 资源 文件 必须 为 message， 否 则 便 会 获取 不 到 自 定义 资源 配置 ， 
Sein 么 之 前 提 到 Bean 的 id 如 果 部 位 message 会 抛 出 异常 。 

protected void initMessageSource() 1 

ConfigurableListableBeanFactory beanFactory = getBeanFactory(); 
if 
(beanFactory.containsLocalBean(MESSAGE SOURCE BEAN NAME)) 
{ 
/如 果 在 配置 中 已 经 配置 了 messageSource ， 那 么 将 
messageSource 提取 并 记录 在 


this.messageSource 中 


this.messageSource = 
beanFactory.getBean(MESSAGE SOURCE BEAN NAME, 
MessageSource. 
class); 
// Make MessageSource aware of parent MessageSource. 
if (this.parent != null && this.messageSource instanceof 
Hierarchical 
MessageSource) 1 
HierarchicalMessageSource hms = 
(HierarchicalMessageSource) this. 
messageSource; 


if (hms.getParentMessageSource() == null) { 


hms.setParentMessageSource(getInternalParentMessageSource()); 
} 
} 
if (logger.isDebugEnabled()) { 
logger.debug(" Using MessageSource [" + this.messageSource 


十 a i 


jelse { 
/如 果 用 户 并 没有 定义 配置 文件 ， 那 么 使 用 临时 的 
DelegatingMessageSource 以 便于 作为 调用 
getMessage 方 法 的 返回 。 
DelegatingMessageSource dms = new 


DelegatingMessageSource(); 


dms.setParentMessageSource(getInternalParentMessageSource()); 


this.messageSource = dms; 


beanFactory.registerSingleton(MESSAGE SOURCE BEAN NAME, 
this.messageSource); 
if (logger.isDebugEnabled()) 1 
logger.debug( "Unable to locate MessageSource with name ' + 
MESSAGE SOURCE BEAN NAME + 


"': using default ["  this.messageSource + "]"); 


j 

通过 读 取 并 将 自 定 义 资源 文件 配置 记录 在 容器 中 ， 那 么 就 可 以 在 
获取 资产 文件 的 时 候 直 接 使 用 了 ， 例 如 ， 在 AbstractApplicationContext 
中 的 获取 资源 文件 属性 的 方法 : 

public String getMessage(String code, Object args[], Locale locale) 
throws NoSuchMessage 

Exception 1 


return getMessageSource().getMessage(code, args, locale); 


其 中 的 getMessageSource() 方 法 正 是 获取 了 之 前 定义 的 自 定 义 资源 
配置 。 
6.6.4 初始 化 ApplicationFventMulticaster 


在 讲解 Spring 的 时 间 传 播 器 之 前 ， 我 们 还 是 先 来 看 一 下 Spring 的 事 
件 监听 的 简单 用 法 。 


(1) 定义 监听 事件 。 
public class TestEvent extends ApplicationEvent { 
public String msg; 
public TestEvent (Object source) 1 
super(source); 
} 
public TestEvent (Object source, String msg) { 
super(source); 
this.msg = msg; 
} 
public void print(){ 
System.out.printIn(msg); 
} 
j 
(2) 定义 监听 器 。 
public class TestListener implements ApplicationListener 1 
public void onApplicationEvent(ApplicationEvent event) 1 
if(event instanceof TestEvent)1 
TestEvent testEvent = (TestEvent)event; 


testEvent .print(); 


j 

j 
(3) 添加 配置 文件 。 

<bean id="testListener" class="com.test.event.TestListener "/> 
(4) 测试 。 

public class Test { 


public static void main(String[] args) 1 
ApplicationContext context = new 
ClassPathXmlA pplicationContext ("classpath: 
applicationContext.xml"); 
TestEvent event = new TestEvent ("hello","msg"); 


context.publishEvent(event); 


j 
当 程 序 运行 时 ，Spring 会 将 发 出 的 TestEvent 事 件 转 给 我 们 自 定义 
的 TestListener 进行 进一步 处 理 。 
或 许 很 多 人 一 下 子 会 反映 出 设计 模式 中 的 观察 者 模式 ， 这 确实 是 
个 典型 的 应 用 ， 可 以 在 比较 关心 的 事件 结束 后 及 时 处 理 。 那 么 我 们 看 
看 ApplicationEventMulticaster 是 如 何 被 初始 化 的 ， 以 确保 功能 的 正确 
运行 。 
initApplicationEventMulticaster 的 方式 比较 简单 ， 无 非 考虑 两 种 情 
Zo 
如 果 用 户 自 定义 了 事件 广播 器 ， 那 么 使 用 用 户 自 定义 的 事件 广播 
Eo 
如 果 用 户 没有 自 定义 事件 广播 器 ， 那 么 使 用 默认 的 
ApplicationEventMulticastero 
protected void initApplicationEventMulticaster() 1 
ConfigurableListableBeanFactory beanFactory = getBeanFactory(); 
if 
(beanFactory.containsLocalBean( APPLICATION EVENT MULTICASTE 
R. BEAN NAME)) { 


this.applicationEventMulticaster — 


beanFactory.getBean(APPLICATION_EVENT_MULTICASTER_BEAN_ 
NAME, 
ApplicationEventMulticaster.class); 
if (logger.isDebugEnabled()) 1 
logger.debug(" Using ApplicationEventMulticaster [" + 
this.application 
EventMulticaster + "]"); 
} 
}else { 
this.applicationEventMulticaster = new 
SimpleA pplicationEventMulticaster 
(beanFactory); 


beanFactory.registerSingleton(APPLICATION_EVENT_MULTICASTER_ 
BEAN_NAME, 
this.applicationEventMulticaster); 
if (logger.isDebugEnabled()) { 
logger.debug(" Unable to locate ApplicationEventMulticaster 
with name ”+ 
APPLICATION EVENT MULTICASTER. BEAN NAME + 


"': using default ["  this.applicationEventMulticaster + "]"); 


) 
按照 之 前 介绍 的 顺序 及 逻辑 ， 我 们 推断 ， 作 为 广播 器 ， 一 定 是 
于 存放 监听 器 并 在 合适 的 时 候 调 用 监听 器 ， 那 么 我 们 不 妨 进入 默认 的 


广播 器 实现 SimpleApplicationEventMulticaster 来 一 探究 竟 。 
其 中 的 一 段 代码 是 我 们 感 兴趣 的 。 
public void multicastEvent(final ApplicationEvent event) { 
for (final ApplicationListener listener : 
getApplicationListeners(event)) 1 
Executor executor = getTaskExecutor(); 
if (executor != null) { 
executor.execute(new Runnable() 1 
(p SuppressWarnings("unchecked") 
public void run() 1 
listener.onApplicationEvent(event); 
} 
y 
j 
else { 


listener.onA pplicationEvent(event); 


} 

可 以 推断 ， 当 产生 Spring 事件 的 时 候 会 默认 使 用 
SimpleApplicationEventMulticaster 的 multicastEvent 来 广播 事件 ， 人 遍历 
所 有 监听 器 ， 并 使 用 监听 器 中 的 onApplicationEvent 方 法 来 进行 监听 器 
的 处 理 。 而 对 于 每 个 监听 器 来 说 其 实 都 可 以 获取 到 产生 的 事件 ， 但 是 
是 否 进 行 处 理 则 由 事件 监听 器 来 决定 。 


6.6.5 注册 监 [ 


之 前 在 介绍 Spring 的 广播 器 时 反复 提 到 了 事件 监听 器 ， 那 么 在 
Spring 注册 监听 器 的 时 候 又 做 了 哪些 逻辑 操作 呢 ? 
protected void registerListeners() { 
// 鲁 编码 方式 注册 的 监听 器 处 理 


for (ApplicationListener<?> listener : getApplicationListeners()) { 


getApplicationEventMulticaster().addA pplicationListener(listener); 
l 
/配置 文件 注册 的 监听 器 处 理 
String[] listenerBeanNames = 
getBeanNamesForType(ApplicationListener.class, 
true, false); 


for (String lisName : listenerBeanNames) 1 


getApplicationEventMulticaster().addApplicationListenerBean(lisName); 
l 


6.7 


完成 BeanFactory 的 初始 化 工作 ， 其 中 包括 ConversionService 的 设 
置 、 配 置 东 结 以 及 非 延 迟 加 载 的 bean 的 初始 化 工作 。 

protected void 
finishBeanFactoryInitialization(ConfigurableListableBeanFactory 
beanFactory) 1 


// Initialize conversion service for this context. 


if 
(beanFactory.containsBean(CONVERSION SERVICE BEAN NAME) 
&& 


beanFactory.isTypeMatch(CONVERSION SERVICE BEAN NAME, 
ConversionService.class)) 1 


beanFactory.setConversionService( 


beanFactory.getBean(CONVERSION SERVICE BEAN NAME, 
ConversionService.class)); 
j 
// Initialize LoadTimeWeaverAware beans early to allow for 
registering their 
transformers early. 
String[] weaverAwareNames = beanFactory.getBeanNamesForType 
(LoadTimeWeaverAware. 
class, false, false); 
for (String weaverAwareName : weaverAwareNames) { 
getBean(weaverAwareName); 
} 
// Stop using the temporary ClassLoader for type matching. 
beanFactory.set TempClassLoader(null); 
/冻结 所 有 的 bean 定 义 ， 说 明 注册 的 bean 定 义 将 不 被 修改 或 任何 
进一步 的 处 理 。 
beanFactory.freezeConfiguration(); 


// Instantiate all remaining (non-lazy-init) singletons. 


/初始 化 剩 下 的 单 实例 〈 非 惰性 的 ) 


beanFactory.preInstantiateSingletons(); 


} 
首先 我 们 来 了 解 一 下 ConversionService 类 所 提供 的 作用 。 
1。ConversionService 的 设置 
之 前 我 们 提 到 过 使 用 自 定 义 类 型 转换 器 从 String 转 换 为 Date 的 方 
式 ， 那 么 ， 在 Spring 中 还 提供 了 另 一 种 转换 方式 : 使 用 Converter。 同 
样 ， 我 们 使 用 一 个 简单 的 示例 来 了 解 下 Converter 的 使 用 方式 。 
(1) 定义 转换 器 。 
public class String2DateConverter implements Converter<String, 
Date? { 
@Override 
public Date convert(String argO) { 
try { 
return DateUtils.parseDate(arg0, 
new String[] { "yyyy-MM-dd HH:mm:ss" }); 
} catch (ParseException e) { 


return null; 


j 
(2) 注册 。 


<bean id="conversionService" 


class="org.Springframework.context.support.ConversionServiceFactoryBea 
n Ww > 
<property name="converters"> 


<list> 


«bean class="String2DateConverter" /> 
</list> 
</property> 
</bean> 
(3) 测试 。 
这 样 便 可 以 使 用 Converter 为 我 们 提供 的 功能 了 ， 下 面 我 们 通过 一 
个 简便 的 方法 来 对 此 直接 测试 。 
public void testStringl'oPhoneNumberConvert() 1 
DefaultConversionService conversionService = new 
DefaultConversionService(); 
conversionService.addConverter(new 
String ToPhoneNumberConverter()); 
String phoneNumberStr = "010-12345678"; 
PhoneNumberModel phoneNumber = 
conversionService.convert(phoneNumberStr, PhoneNumber 
Model.class); 
Assert.assertEquals("010", phoneNumber.getAreaCode()); 
通过 以 上 的 功能 我 们 看 到 了 Converter 以 及 ConversionService 提 供 
的 便利 功能 ， 其 中 的 配置 就 是 在 当前 函数 中 被 初始 化 的 。 
2. 冻结 配置 
冻结 所 有 的 bean 定 义 ， 说 明 注 册 的 bean 定 义 将 不 被 修改 或 进行 任 
何 进一步 的 处 理 。 
public void freezeConfiguration() { 
this.configurationFrozen = true; 


synchronized (this.beanDefinitionMap) { 


this.frozenBeanDefinitionNames = 
StringUtils.toStringArray(this.bean 


DefinitionNames); 


j 
3. 初始 化 非 延迟 加 载 
ApplicationContext 实现 的 默认 行为 就 是 在 启动 时 将 所 有 单 例 bean 
提前 进行 实例 化 。 提 前 实例 化 意味 着 作为 初始 化 过 程 的 一 部 分 ， 
ApplicationContext 实 例会 创建 并 配置 所 有 的 单 例 bean。 通 常情 况 下 这 
是 一 件 好 事 ， 因 为 这 样 在 配置 中 的 任何 错误 就 会 即刻 被 发 现 (否则 的 
话 可 能 要 花 几 个 小 时 甚至 几 天 ) 。 而 这 个 实例 化 的 过 程 就 是 在 
finishBeanFactoryInitialization 中 完成 的 。 
public void preInstantiateSingletons() throws BeansException { 
if (this.logger.isInfoEnabled()) 1 
this.logger.info(" Pre-instantiating singletons in " + this); 
j 
List<String> beanNames; 
synchronized (this.beanDefinitionMap) { 
// Iterate over a copy to allow for init methods which in turn 
register new 
bean definitions. 
// While this may not be part of the regular factory bootstrap, it 
does 
otherwise work fine. 
beanNames = new ArrayList<String> 
(this.beanDefinitionNames); 


} 


for (String beanName : beanNames) { 
RootBeanDefinition bd = 
getMergedLocalBeanDefinition(beanName); 
if (!bd.isAbstract() && bd.isSingleton() && !bd.isLazylnit()) { 
if (isFactoryBean(beanName)) 1 
final FactoryBean<?> factory = (FactoryBean<?>) 
getBean(FACTORY_ 
BEAN PREFIX + beanName); 
boolean isEagerInit; 
if (System.getSecurityManager() != null && factory 
instanceof 
SmartFactoryBean) { 
isEagerInit = AccessController.doPrivileged(new 
PrivilegedAction 
<Boolean>() { 
public Boolean run() { 
return ((SmartFactoryBean<?>) 
factory).isEagerInit(); 
} 
}, getAccessControlContext()); 
} 
else { 
isEagerInit = (factory instanceof SmartFactoryBean && 
((SmartFactoryBean<?>) factory).isEagerInit()); 
} 
if (isEagerlInit) { 


getBean(beanName); 


j 
else { 


getBean(beanName); 


6.8 finishRefresh 


在 Spring 中 还 提供 了 Lifecycle 接 口 ，Lifecycle 中 包含 startystop 方 
法 ， 实 现 此 接口 后 Spring 会 保证 在 启动 的 时 候 调 用 其 start 方 法 开始 生命 
周期 ， 并 在 Spring 关闭 的 时 候 调 用 stop 方 法 来 结束 生命 周期 ， 通 常用 来 
配置 后 台 程 序 ， 在 启动 后 一 直 运 行 (如 对 MQ 进行 轮 询 等 ) 。 而 
ApplicationContext 的 初始 化 最 后 正 是 保证 了 这 一 功能 的 实现 。 
protected void finishRefresh() 1 
initLifecycleProcessor(); 
// Propagate refresh to lifecycle processor first. 
getLifecycleProcessor().onRefresh(); 
// Publish the final event. 
publishEvent(new ContextRefreshedEvent(this)); 
} 
1. initLifecycleProcessor 
当 ApplicationContext 启 动 或 停止 时 ， 它 会 通过 LifecycleProcessor 
来 与 所 有 声明 的 bean 的 周期 做 状态 更 新 ， 而 在 LifecycleProcessor 的 使 
用 前 首先 需要 初始 化 。 


protected void initLifecycleProcessor() 1 
ConfigurableListableBeanFactory beanFactory = getBeanFactory(); 
if 

(beanFactory.containsLocalBean(LIFECYCLE PROCESSOR BEAN NA 
ME)) t 


this.lifecycleProcessor = 


beanFactory.getBean(LIFECYCLE PROCESSOR BEAN NAME, 
LifecycleProcessor.class); 
if (logger.isDebugEnabled()) { 
logger.debug( Using LifecycleProcessor [" + 
this.lifecycleProcessor + "]"); 
} 
jelse { 
DefaultLifecycleProcessor defaultProcessor = new 
DefaultLifecycleProcessor(); 
defaultProcessor.setBeanFactory(beanFactory); 


this.lifecycleProcessor = defaultProcessor; 


beanFactory.registerSingleton(LIFECYCLE_PROCESSOR_BEAN_NAM 
E, 
this.lifecycleProcessor); 
if (logger.isDebugEnabled()) { 
logger.debug(" Unable to locate LifecycleProcessor with name 
HE 
LIFECYCLE PROCESSOR BEAN NAME + 


"': using default [" + this.lifecycleProcessor + "]"); 


} 
2. onRefresh 
启动 所 有 实现 了 Lifecycle 接 口 的 bean。 
public void onRefresh() { 
startBeans(true); 
this.running - true; 
j 
private void startBeans(boolean autoStartupOnly) 1 
Map<String, Lifecycle» lifecycleBeans = getLifecycleBeans(); 
Map<Integer, LifecycleGroup> phases = new HashMapc Integer, 
LifecycleGroup>(); 
for (Map.Entry<String, ? extends Lifecycle> entry : 
lifecycleBeans.entrySet()) { 
Lifecycle bean = entry.getValue(); 
if (lautoStartupOnly || (bean instanceof SmartLifecycle && 
((SmartLifecycle) 
bean).isAutoStartup())) 1 
int phase = getPhase(bean); 
LifecycleGroup group = phases.get(phase); 
if (group == null) 1 
group 7 new LifecycleGroup(phase, 
this.timeoutPerShutdownPhase, 
lifecycleBeans, autoStartupOnly); 
phases.put(phase, group); 


group.add(entry.getKey(), bean); 


i 
if (phases.size() > 0) { 
List<Integer> keys = new ArrayList<Integer>(phases.keySet()); 
Collections.sort(keys); 
for (Integer key : keys) { 
phases. get(key).start(); 


} 
3. publishEvent 
当 完 成 ApplicationContext 初 始 化 的 时 候 ， 要 通过 Spring 中 的 事件 
发 布 机 制 来 发 出 Context RefreshedEvent 事 件 ， 以 保证 对 应 的 监听 器 可 
以 做 进一步 的 逻辑 处 理 。 
public void publishEvent(ApplicationEvent event) { 
Assert.notNull(event, "Event must not be null"); 
if (logger.isTraceEnabled()) { 
logger.trace(" Publishing event in " + getDisplayName() + ": " + 
event); 
j 
getApplicationEventMulticaster().multicastEvent(event); 
if (this.parent != null) { 
this.parent.publishEvent(event); 


第 7 章 AOP 


我 们 知道 ， 使 用 面向 对 象 编程 (OOP) 有 一 些 星 端 ， 当 需要 为 多 
个 不 具有 继承 关系 的 对 象 引 入 同一 个 公共 行为 时 ， 例 如 日 志 、 安 全 检 
测 等 ， 我 们 只 有 在 每 个 对 象 里 引用 公共 行为 ， 这 样 程 序 中 融 产 生 了 大 
量 的 重复 代码 ， 程 序 就 不 便于 维护 了 ， 所 以 就 有 了 一 个 对 面向 对 象 编 
程 的 补充 ， 即 面向 方面 编程 《AOP) ，AOP 所 关注 的 方向 是 横向 的 ， 
不 同 于 OOP 的 纵向 。 

Spring 中 提供 了 AOP 的 实现 ， 但 是 在 低 版 本 Spring 中 定义 一 个 切面 
是 比较 麻烦 的 ， 需 要 实现 特定 的 接口 ， 并 进行 一 些 较为 复杂 的 配置 。 
低 版 本 Spring AOP 的 配置 是 被 批评 最 多 的 地 方 。Spring 听 取 了 这 方面 
的 批评 声音 ， 并 下 决心 彻底 改变 这 一 现状 。 在 Spring 2.0 中 ，Spring 
AOP 已 经 焕然 一 新 ， 你 可 以 使 用 @AspectJ 注 解 非常 容易 地 定义 一 个 切 
面 ， 不 需要 实现 任何 的 接口 。 

Spring 2.0 采 用 @AspectJ 注 解 对 POJO 进 行 标注 ， 从 而 定义 一 个 包 
含 切 点 信息 和 增强 横 切 逻辑 的 切面 。Spring 2.0 可 以 将 这 个 切面 织 入 到 
匹配 的 目标 Bean 中 。@AspectJ 注 解 使 用 AspectJ 切 点 表达 式 语 法 进行 雪 
点 定义 ， 可 以 通过 切 点 冰 数 、 运 算 符 、 通 配 符 等 高 级 功能 进行 切 点 定 
义 ， 拥 有 强大 的 连接 点 描述 能 力 。 我 们 先 来 直观 地 浏览 一 下 Spring 中 
的 AOP 实 现 。 


7.1 AOP 不 


(1) 创建 用 于 拦截 的 bean。 

在 实际 工作 中 ， 此 bean 可 能 是 满足 业务 需要 的 核心 逻辑 ， 例 如 test 
方法 中 可 能 会 封装 着 某 个 核心 业务 ， 但 是 ， 如 果 我 们 想 在 test 前 后 加 入 
日 志 来 跟 中 调试， 如果 和 直接 修改 源码 并 不 符合 面向 对 销 的 设计 方法 ， 


而 且 随 意 改动 原 有 代码 也 会 造成 一 定 的 风险 ， 还 好 接 下 来 的 Spring 帮 
我 们 做 到 了 这 一 点 。 
public class TestBean{ 
private String testStr — "testStr"; 
public String getTestStr() 1 
return testStr; 
j 
public void setTestStr(String testStr) { 
this.testStr - testStr; 
j 
public void test()1 


System.out.println(" test"); 


j 
(2) 创建 Advisor。 

Spring 中 据 弃 了 最 原始 的 繁杂 配置 方式 而 采用 (9 Aspect E HW 
POJO 进 行 标注 ， 使 AOP 的 工作 大 大 简化 ， 例 如 ， 在 AspectJTest 类 中 ， 
我 们 要 做 的 就 是 在 所 有 类 的 test 方 法 执行 前 在 控制 台中 打印 
beforeTest， 而 在 所 有 类 的 test 方 法 执行 后 打印 afterTest， 同 时 又 使 用 环 
绕 的 方式 在 所 有 类 的 方法 执行 前 后 再 次 分 别 打 EDbeforel 和 after1。 

(QAspect 

public class AspectJTest { 

(QPointcut(" execution(* *.test(..))") 
public void test()1 

j 

@Before("test()") 

public void beforeTest(){ 


System.out.printIn("beforeTest"); 
j 
@After("test()") 
public void afterTest(){ 
System.out.printIn("afterTest"); 
j 
@Around("test()") 
public Object arountTest(ProceedingJoinPoint p){ 
System.out.printIn("before1"); 
Object o=null; 
try { 
o = p.proceed(); 
} catch (Throwable e) { 
e.printStackTrace(); 
} 
System.out.printIn("after1"); 


return 0; 


j 
(3) 创建 配置 文件 。 

XML 是 Spring 的 基础 。 尽 管 Spring 一 再 简化 配置 ， 并 且 大 有 使 用 
注解 取代 XML 配置 之 势 ， 但 是 无 论 如 何 ， 至 少 现 在 XML 还 是 Spring 的 
基础 。 要 在 Spring 中 开局 AOP 功 能 ， 还 需要 在 配置 文件 中 作 如 下 声 
BB: 

<?xml version="1.0" encoding="UTF-8"?> 

«beans xmlns-"http://www.Springframework.org/schema/beans" 


xmins:xsi-"http://www.w3.0rg/2001/XMLSchema-instance" 


xmlns:aop-"http://www.Springframework.org/schema/aop" 


xmlns:context-"http://www.Springframework.org/schema/context" 


xsi:schemaLocation-"http://www.Springframework.org/schema/beans 
http://www. Springframework.org/schema/beans/Spring-beans- 
3.0.xsd 
http://www. Springframework.org/schema/aop 
http://www. Springframework.org/schema/aop/Spring-aop-3.0.xsd 
http://www. Springframework.org/schema/context 
http://www.Springframework.org/schema/context/Spring- 
context- 
3.0.xsd 
"> 
«aop:aspectj-autoproxy /> 
<bean id="test" class-" test. TestBean"/» 
<bean class="test.AspectJTest"/> 
</beans> 
(4) 测试 。 
经 过 以 上 步骤 后 ， 便 可 以 验证 Spring 的 AOP 为 我 们 提供 的 神奇 效 
RS o 
public static void main(String[] args) { 
ApplicationContext bf = new 
ClassPathXmlApplicationContext("aspectTest.xml"); 
TestBean bean=(TestBean) bf.getBean("test"); 
bean.test(); 
} 
不 出 意外 ， 我 们 会 看 到 控制 台中 打印 了 如 下 代码 : 


beforeTest 

before1 

test 

afterTest 

after1 

Spring 实现 了 对 所 有 类 的 test 方 法 进行 增强 ， 使 辅助 功能 可 以 独立 
于 核心 业务 之 外 ， 方 便 与 程序 的 扩展 和 解 耦 。 

那么 ，Spring 究 竟 是 如 何 实现 AOP 的 呢 ? 首先 我 们 知道 ，Spring 是 
否 支 持 注解 的 AOP 是 由 一 个 配置 文件 控制 的 ， 也 就 是 <aop:aspectj- 
autoproxy />， 当 在 配置 文件 中 声明 了 这 和 句 配 置 的 时 候 ，Spring 就 会 支 
持 注解 的 AOP， 那 么 我 们 的 分 析 就 从 这 名 注解 开始 。 


= AY = 


L2 AOP ñ 


之 前 讲 过 Spring 中 的 目 定 义 注解 ， 如 果 声 明了 自 定义 的 注解 ， 那 
么 就 一 定 会 在 程序 中 的 某 个 地 方 注册 了 对 应 的 解析 器 。 我 们 搜索 整个 
代码 ， 尝 试 找到 注册 的 地 方 ， 全 局 搜索 后 我 们 发 现 了 在 
AopNamespaceHandler 中 对 应 着 这 样 一段 函 数 : 
public void init() 1 
// In 2.0 XSD as well as in 2.1 XSD. 
registerBeanDefinitionParser(" config", new 
ConfigBeanDefinitionParser()); 
registerBeanDefinitionParser("aspectj-autoproxy", new 
AspectJAutoProxyBean 
DefinitionParser()); 
registerBeanDefinitionDecorator("scoped-proxy", new 


ScopedProxyBeanDefinition 


Decorator()); 

// Only in 2.0 XSD: moved to context namespace as of 2.1 

registerBeanDefinitionParser("Spring-configured", new 
SpringConfiguredBean 

DefinitionParser()); 

j 

此 处 不 再 对 Spring 中 的 自 定义 注解 方式 进行 讨论 。 有 兴趣 的 读者 
可 以 回顾 之 前 的 内 容 。 

我 们 可 以 得 知 ， 在 解析 配置 文件 的 时 候 ， 一 旦 遇 到 aspectj- 
autoproxy 注解 时 就 会 使 用 解析 器 AspectJAutoProxyBeanDefinitionParser 
进行 解析 ， 那 么 我 们 来 看 一 看 AspectJAutoProxyBean DefinitionParser 
的 内 部 实现 。 


Zl itHAnnotationAwareAspectJAutoProxy Creator 


所 有 解析 器 ， 因 为 是 对 BeanDefinitionParser 接 口 的 统一 实现 ， 入 
口 都 是 从 parse 国 数 开 始 的 ，AspecUJAutoProxyBeanDefinitionParser 的 
parsePK|ZX 3H F : 

public BeanDefinition parse(Element element, ParserContext 
parserContext) { 


// 7X: BB AnnotationAwareAspectJ AutoProxyCreator 


AopNamespaceUtils.registerAspectJAnnotationAutoProxyCreatorIf Necessa 
ry 

(parserContext, element); 

/对 于 注解 中 子 类 的 处 理 

extendBeanDefinition(element, parserContext); 


return null; 


} 
其 中 registerAspectJAnnotationAutoProxyCreatorIfNecessary 国 数 是 
我 们 比较 关心 的 ， 也 是 关键 逻辑 的 实现 。 
[e 
* JAH AnnotationAwareAspectJAutoProxyCreator 
* @param parserContext 
* @param sourceElement 
*/ 
public static void 
registerAspectJAnnotationAutoProxyCreatorlfNecessary( 
ParserContext parserContext, Element sourceElement) { 
/注册 或 升级 AutoProxyCreator 定义 beanName 为 
org.Springframework.aop.config. 
internalAutoProxyCreatorB* BeanDefinition 
BeanDefinition beanDefinition = 
AopConfigUtils.registerAspectJAnnotationAuto 
ProxyCreatorlfNecessary( 
parserContext.getRegistry(), 
parserContext.extractSource(sourceElement)); 
// 对 于 proxy-target-class 以 及 expose-proxy 属 性 的 处 理 
useClassProxyingIfNecessary(parserContext.getRegistry(), 
sourceElement); 
// 注 册 组 件 并 通知 ， 便 于 监听 器 做 进一步 处 理 
// 其 中 beanDefinition 的 className 为 
AnnotationAwareAspectJAutoProxyCreator 


registerComponentIfNecessary(beanDefinition, parserContext); 


在 registerAspectJ E cent es a 方法 中 主 
gases 3 件 事情 ， 基 本 上 每 行 代码 就 是 一 个 完整 的 逻辑 。 
; a ee 
对 于 AOP 的 实现 ， 基 本 上 都 是 靠 
AnnotationAwareAspectJAutoProxyCreator 去 完成 ， 它 可 以 根据 @Point 
注解 定义 的 切 点 来 自动 代理 相 匹配 的 bean。 但 是 为 了 配置 简便 ， 
Spring 使 用 了 自 定 义 配 置 来 帮助 我 们 自动 注册 
AnnotationAwareAspectJAutoProxyCreator， 其 注册 过 程 就 是 在 这 里 实 
现 的 。 
public static BeanDefinition 
registerAspectJAnnotationAutoProxyCreatorlfNecessary 
(BeanDefinitionRegistry registry, Object source) { 
return 
registerOrEscalateApcAsRequired(AnnotationAwareAspectJAutoProxyCre 
ator. 
class, registry, source); 
} 
private static BeanDefinition registerOrEscalateA pcAsRequired(Class 
cls, BeanDefinition 
Registry registry, Object source) { 
Assert.notNull(registry, "BeanDefinitionRegistry must not be 
null"); 
// 如 果 已 经 存在 了 目 动 代理 创建 器 且 存 在 的 自动 代 理 创建 器 与 现 
在 的 不 一 致 那么 需要 根据 优先 级 来 判断 到 底 需 要 使 用 哪 
if 
(registry.containsBeanDefinition( AUTO PROXY CREATOR BEAN NA 
ME)) { 


//AUTO PROXY CREATOR BEAN NAME = 
/l"org.Springframework.aop.config.internal AutoProxyCreator"; 
BeanDefinition apcDefinition = 
registry.getBeanDefinition( AUTO PROXY 
CREATOR, BEAN NAME); 
if (!cls.getName().equals(apcDefinition.getBeanClassName())) 1 
int currentPriority — 
findPriorityForClass(apcDefinition.getBean&nbsp;ClassName()); 
int requiredPriority = findPriorityForClass(cls); 
if (currentPriority < requiredPriority) { 
/改变 bean 最 重要 的 就 是 改变 bean 所 对 应 的 className 属 性 


apcDefinition.setBeanClassName(cls.getName()); 


// 如 果 已 经 存在 自动 代理 创建 器 并 且 与 将 要 创建 的 一 致 ， 那 

么 无 需 再 此 创建 

return null; 

} 

RootBeanDefinition beanDefinition = new 
RootBeanDefinition(cls); 

beanDefinition.setSource(source); 

beanDefinition.getProperty Values().add(" order", 

Ordered.HIGHEST PRECEDENCE); 


beanDefinition.setRole(BeanDefinition.ROLE INFRASTRUCTURE); 
//AUTO PROXY CREATOR BEAN NAME - 


//"org.Springframework.aop.config.internalAutoProxyCreator"; 


registry.registerBeanDefinition(AUTO PROXY CREATOR BEAN NAM 
E, beanDefinition); 
return beanDefinition; 
j 
以 上 代码 中 实现 了 自动 注册 
AnnotationAwareAspectJAutoProxyCreator 类 的 功能 ， 同 时 这 里 还 涉及 
了 一 个 优先 级 的 问题 ， 如 果 已 经 存在 了 自动 代理 创建 器 ， 而 且 存 在 的 
自动 代理 创建 器 与 现在 的 不 一 致 ， 那 么 需要 根据 优先 级 来 判断 到 底 需 
要 使 用 哪个 。 
2。 处 理 proxy-target-class 以 及 expose-proxy 属 性 
useClassProxyingIfNecessary 实 现 了 proxy-target-class 属 性 以 及 
expose-proxy 属 性 的 处 理 。 
private static void 
useClassProxyingIfNecessary(BeanDefinitionRegistry registry, Element 
sourceElement) { 
if (sourceElement !- null) { 
// 对 于 proxy-target-class 属 性 的 处 理 。 
boolean proxyTargetClass = 
Boolean.valueOf(sourceElement.getAttribute 
(PROXY TARGET CLASS ATTRIBUTE)); 
if (proxyTargetClass) 1 


AopConfigUtils.forceAutoProxyCreatorToUseClassProxying(registry); 
} 
/对 于 expose-proxy 属 性 的 处 理 


boolean exposeProxy = 
Boolean.valueOf(sourceElement.getAttribute (EXPOSE _ 

PROXY ATTRIBUTE)); 

if (exposeProxy) 1 


AopConfigUtils.forceAutoProxyCreatorToExposeProxy(registry); 
} 


} 
// 强 制 使 用 的 过 程 其 实 也 是 一 个 属性 设置 的 过 程 
public static void 
forceAutoProxyCreatorToUseClassProxying(BeanDefinitionRegistry 
registry) 1 
if 
(registry.containsBeanDefinition(AUTO PROXY CREATOR BEAN NA 
ME)) { 
BeanDefinition definition = 
registry.getBeanDefinition( AUTO PROXY CREATOR 
BEAN NAME); 
definition.getProperty Values().add(" proxy TargetClass", 
Boolean. TRUE); 
j 
j 
static void 
forceAutoProxyCreatorToExposeProxy(BeanDefinitionRegistry registry) 1 
if 
(registry.containsBeanDefinition(AUTO PROXY CREATOR, BEAN NA 


ME)) t 
BeanDefinition definition = 
registry.getBeanDefinition( AUTO PROXY CREATOR 
BEAN NAME); 
definition.getProperty Values().add(""exposeProxy", 
Boolean. TRUE); 
} 
} 
proxy-target-class: Spring AOP 部 分 使 用 JDK 动 态 代 理 或 者 CGLIB 
来 为 目标 对 象 创建 代理 。 (建议 尽量 使 用 JDK 的 动态 代理 ) ， 如 果 被 
代理 的 目标 对 象 实 现 了 至 少 一 个 接口 ， 则 会 使 用 JDK 动 态 代理 。 所 有 
该 目标 类 型 实现 的 接口 都 将 被 代理 。 若 该 目标 对 象 没 有 实现 任何 接 
口 ， 则 创建 一 个 CGLIB 代 理 。 如 果 你 希望 强制 使 用 CGLIB 代 理 ， (HI 
如 希望 代理 目标 对 象 的 所 有 方法 ， 而 不 只 是 实现 自 接口 的 方法 ) AB 
可 以 。 但 是 需要 考虑 以 下 两 个 问题 。 
«7523851 (advise) Final 方 法 ， 因 为 它们 不 能 被 覆 写 。 
售 你 需要 将 CGLIB 二 进 制 发 行 包 放 在 classpath 下 面 。 
与 之 相 较 ，JDK 本 身 就 提供 了 动态 代理 ， 强 制 使 用 CGLIB 代 理 需 
要 将 <aop:config> 的 proxy-target-class 属 性 设 为 true: 
«aop:config proxy-target-class-" true"? ... </aop:config> 
当 需 要 使 用 CGLIB 代 理 和 @AspectJ 自 动 代理 支持 ， 可 以 按照 以 下 
方式 设置 <aop:aspectj-autoproxy> 的 proxy-target-class 属 性 : 
<aop:aspectj-autoproxy proxy-target-class="true"/> 
而 实际 使 用 的 过 程 中 才 会 发 现 细节 问题 的 差别 ，The devil is in the 
detail. 
JDK 动 态 代理 : 其 代理 对 象 必须 是 某 个 接口 的 实现 ， 它 是 通过 在 
运行 期 间 创 建 一 个 接口 的 实现 类 来 完成 对 目标 对 象 的 代理 。 


CGLIB 代理 : 实现 原理 类 似 于 IDK 动态 代理 ， 只 是 它 在 运行 期 
间 生 成 的 代理 对 象 是 针对 目标 类 扩展 的 子 类 。CGLIB 是 高 效 的 代码 生 
成 包 ， 底 层 是 依靠 ASM (开源 的 Java 字 节 码 编辑 类 库 ) 操作 字 节 码 实 
现 的 ， 性 能 比 JDK 强 。 
expose-proxy: 有 时 候 目标 对 象 内 部 的 自我 调用 将 无 法 实施 切面 中 
的 增强 ， 如 下 示例 : 
public interface AService { 
public void a(); 
public void b(); 


} 


@Service() 
public class AServiceImpl1 implements AService{ 


@Transactional(propagation = Propagation.REQUIRED) 
public void a() { 
this.b(); 


} 
@Transactional(propagation = Propagation. REQUIRES. NEW) 


public void b() 1 
i 


} 
此 处 的 this 指 向 目标 对 象 ， 因 此 调用 this.b0 将 不 会 执行 b 事 务 切 


面 ， 即 不 会 执行 事务 增强 ， 因 此 b 方 法 的 事务 定义 
“@Transactional(propagation = Propagation.REQUIRES_NEW)” 将 不 会 实 
施 ， 为 了 解决 这 个 问题 ， 我 们 可 以 这 样 做 : 

«aop:aspectj-autoproxy expose-proxy="true"/> 


然后 将 以 上 代码 中 的 “this.b0;”* 修 改 为 “((AService) 
AopContext.currentProxy()).b();” 即 可 。 通 过 以 上 的 修改 便 可 以 完成 对 a 


和 Pb 方法 的 同时 增强 。 
最 后 注册 组 件 并 通知 ， 便 于 监听 器 做 进一步 处 理 ， 这 里 就 不 再 一 
ERUNT. 


7.3 创建 AOP 代 理 


上 文中 讲解 了 通过 自 定 义 配 置 完 成 了 对 
AnnotationAwareAspectJAutoProxyCreator 类 型 的 自动 注册 ， 那 么 这 个 
类 到 底 做 了 什么 工作 来 完成 AOP 的 操作 呢 ? 首先 我 们 看 看 Annotation 
AwareAspectJAutoProxyCreator 类 的 层次 结构 ， 如 图 7-1 所 示 。 


4 KJ AnnotationAwareAspectJAutoproxyCreator 
4 (9 AspectlAwareAdvisorAutoProxyCreator 
4 (9^ AbstractAdvisorAutoProxyCreator 
4 (9^ AbstractAutoProxyCreator 
4 (9 ProxyConfig 
(9 Object 
Q Serializable 


@ AoplnfrastructureBean 
Q BeanClassLoaderAware 
Q Aware 
4 © BeanFactoryAware 
Q Aware 
Q Ordered 
@  SmartinstantiationAwareBeanPostProcessor 
El 


© Instantiation&wareBeanPostProcessor 


© BeanPostProcessor 


图 7-1 AnnotationAwareAspectJAutoProxyCreator 类 的 层次 结构 


在 类 的 层级 中 ， 我 们 看 到 


AnnotationAwareAspectJAutoProxyCreator 实现 了 BeanPostProcessor 接 


口 ， 而 实现 BeanPostProcessor 后 ， 当 Spring 加 载 这 个 Bean 时 会 在 实例 化 
前 调用 其 postProcess AfterInitialization 方 法 ， 而 我 们 对 于 AOP 人 逻辑 的 分 
析 也 由 此 开始 。 
在 父 类 AbstractAutoProxyCreator 的 postProcessAfterInitialization 中 
代码 如 下 : 
public Object postProcessAfterInitialization(Object bean, String 
beanName) throws BeansException { 
if (bean != null) { 
/根据 给 定 的 bean 的 class 和 name 构 建 出 个 key， 格 式 : 
beanClassName_beanName 
Object cacheKey = getCacheKey(bean.getClass(), beanName); 
if (!this.earlyProxyReferences.contains(cacheKey)) { 
/如 果 它 适合 被 代理 , 则 需要 封装 指定 bean。 


return wrapIfNecessary(bean, beanName, cacheKey); 


} 


return bean; 


} 
protected Object wrapIfNecessary(Object bean, String beanName, 


Object cacheKey) { 
/如 果 已 经 处 理 过 
if (this.targetSourcedBeans.contains(beanName)) { 
return bean; 
j 
/无 需 增强 
if (this.nonAdvisedBeans.contains(cacheKey)) { 


return bean; 


/给 定 的 bean 类 是 否 代表 一 个 基础 设施 类 ， 基 础 设施 类 不 应 代理 ， 
或 者 配置 了 指定 bean 不 需要 自动 代理 
if (isInfrastructureClass(bean.getClass()) || 
shouldSkip(bean.getClass(), 
beanName)) 1 
this.nonAdvisedBeans.add(cacheKey); 
return bean; 
j 
/如 果 存 在 增强 方法 则 创建 代理 
Object[] specificInterceptors = 
getAdvicesAndAdvisorsForBean(bean.getClass(), 
beanName, null); 
// 如 果 获 取 到 了 增强 则 需要 针对 增强 创建 代理 
if (specificInterceptors '- DO NOT PROXY) ( 
this.advisedBeans.add(cacheKey); 
/创建 代理 
Object proxy = createProxy(bean.getClass(), beanName, 
specificInterceptors, 
new SingletonTargetSource(bean)); 
this.proxy Types.put(cacheKey, proxy.getClass()); 
return proxy; 
j 
this.nonAdvisedBeans.add(cacheK ey); 


return bean; 


孙 数 中 我 们 已 经 看 到 了 代理 创建 的 骏 形 。 当 然 ， 真 正 开 始 之 前 还 
需要 经 过 一 些 判 断 ， 比 如 是 否 已 经 处 理 过 或 者 是 否 是 需要 跳 过 的 
bean， 而 真正 创建 代理 的 代码 是 从 getAdvicesAnd AdvisorsForBean 开 
始 的 。 
创建 代理 主要 包含 了 两 个 步骤 : 
(1) 获取 增强 方法 或 者 增强 器 ; 
(2) 根据 获取 的 增强 进行 代理 。 
核心 逻辑 的 时 序 图 如 图 7-2 所 示 。 
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虽然 看 似 简单 ， 但 是 每 个 步骤 中 都 经 历 了 大 量 复杂 的 逻辑 。 首 先 
来 看 看 获取 增强 方法 的 实现 逻辑 。 
@Override 
protected Object[] getAdvicesAndAdvisorsForBean(Class beanClass, 
String beanName, 
TargetSource targetSource) { 
List advisors = findEligibleAdvisors(beanClass, beanName); 
if (advisors.isEmpty()) { 
return DO_NOT_PROXY; 
} 
return advisors.toArray(); 
} 
protected List<Advisor> findEligibleAdvisors(Class beanClass, String 
beanName) { 
List<Advisor> candidateAdvisors = findCandidateAdvisors(); 
List<Advisor> eligibleAdvisors = 
findAdvisorsThatCanApply(candidateA dvisors, 
beanClass, beanName); 
extendAdvisors(eligibleAdvisors); 
if (leligibleAdvisors.isEmpty()) { 
eligibleAdvisors = sortAdvisors(eligibleAdvisors); 
j 


return eligibleAdvisors; 


对 于 指定 bean 的 增强 方法 的 获取 一 定 是 包含 两 个 步骤 的 ， 获 取 所 
有 的 增强 以 及 寻找 所 有 增强 中 适用 于 bean 的 增强 并 应 用 ， 那 么 
findCandidateAdvisors 与 findAdvisorsThatCanApply 便 是 做 了 这 两 件 事 
情 。 当 然 ， 如 果 无 法 找到 对 应 的 增强 器 便 返 回 DO NOT PROXY, 其 
中 DO_NOT_PROXY=null. 


7.3.1 增 


由 于 我 们 分 析 的 是 使 用 注解 进行 的 AOP， 所 以 对 于 
findCandidateAdvisors 的 实现 其 实 是 
AnnotationAwareAspectJAutoProxyCreator 类 完成 的 ， 我 们 继续 跟踪 
AnnotationAwareAspectJAuto ProxyCreator 的 findCandidateAdvisors 方 
法 。 

@Override 

protected List<Advisor> findCandidateAdvisors() { 

// 当 使 用 注解 方式 配置 AOP 的 时 候 并 不 是 丢弃 了 对 XML 配 置 的 
支持 ， 

// 在 这 里 调用 父 类 方法 加 载 配 置 文件 中 的 AOP 声 明 

List<Advisor> advisors = super.findCandidateAdvisors(); 


// Build Advisors for all AspectJ aspects in the bean factory. 


advisors.addAll(this.aspectJ AdvisorsBuilder.buildAspectJAdvisors()); 
return advisors; 
} 
AnnotationAwareAspectJAutoProxyCreator 间 接 继 承 了 
AbstractAdvisorAutoProxyCreator， 在 实现 获取 增强 的 方法 中 除了 保留 
父 类 的 获取 配置 文件 中 定义 的 增强 外 ， 同 时 添加 了 获取 Bean 的 注解 增 


强 的 功能 ， 那 么 其 实现 正 是 由 
this.aspectJAdvisorsBuilder.buildAspectJAdvisors() 来 实现 的 。 

在 真正 研究 代码 之 前 读者 可 以 尝试 着 自己 去 想象 一 下 解析 思路 ， 
看 看 自己 的 实现 与 Spring 是 否 有 差别 呢 ? 或 者 我 们 一 改 以 往 的 方式 ， 
先 来 了 解 国 数 提供 的 大 概 功 能 框架 ， 读 者 可 以 在 头脑 中 党 试 实现 这 些 
功能 点 ， 看 看 是 否 有 思路 。 

(1) 获取 所 有 beanName， 这 一 步骤 中 所 有 在 beanFacotry 中 注册 
的 Bean 都 会 被 提取 出 来 。 

(2) 遍历 所 有 beanName， 并 找 出 声明 Aspect 注 解 的 类 ， 进 行进 
一 步 的 处 理 。 

(3) 对 标记 为 AspectJ 注 解 的 类 进行 增强 器 的 提取 。 

(4) 将 提取 结果 加 入 缓存 。 

现在 我 们 来 看 看 函数 实现 ， 对 Spring 中 所 有 的 类 进行 分 析 ， 提 取 
Advisoro 

public List<Advisor> buildAspectJAdvisors() { 

List<String> aspectNames = null; 
synchronized (this) { 
aspectNames = this.aspectBeanNames; 
if (aspectNames == null) { 
List<Advisor> advisors = new LinkedList<Advisor>(); 
aspectNames = new LinkedList<String>(); 
/获取 所 有 的 beanName 
String[] beanNames 
=BeanFactoryUtils.beanNamesForIypeIncludingAncestors 
(this.beanFactory, Object.class, true, false); 
/循环 所 有 的 beanName 找 出 对 应 的 增强 方法 


for (String beanName : beanNames) { 


/不 合法 的 bean 则 略 过 ， 由 子 类 定义 规则 ， 默 认 返 回 true 
if (lisEligibleBean(beanName)) 1 
continue; 
j 
/获取 对 应 的 bean 的 类 型 
Class beanType = this.beanFactory.getType(beanName); 
if (beanType == null) { 
continue; 
} 
/如 果 存 在 Aspect 注 解 
if (this.advisorFactory.isAspect(beanType)) 1 
aspectNames.add(beanName); 
AspectMetadata amd = new AspectMetadata(beanType, 
beanName); 
if (amd.getAjType().getPerClause().getKind() == 
PerClauseKind. 
SINGLETON) { 
MetadataAwareAspectInstanceFactory factory = 
new BeanFactoryAspectInstanceFactory(this. 
beanFactory, beanName); 
/解析 标记 AspectJ 注 解 中 的 增强 方法 
List<Advisor> classAdvisors = this.advisorFactory. 
getAdvisors(factory); 
if (this.beanFactory.isSingleton(beanName)) 1 
this.advisorsCache.put(beanName, classAdvisors); 
j 


else { 


this.aspectFactoryCache.put(beanName, factory); 

j 

advisors.addAll(classAdvisors); 

jelse 1 

// Per target or per this. 

if (this.beanFactory.isSingleton(beanName)) 1 
throw new IllegalArgumentException(" Bean with 

name 

"+ beanName + 
"' js a singleton, but aspect instantiation 
model is not singleton"); 

} 

MetadataAwareAspectInstanceFactory factory = 
new PrototypeAspectInstanceFactory(this. 
beanFactory, beanName); 


this.aspectFactoryCache.put(beanName, factory); 


advisors.addAll(this.advisorFactory.getAdvisors(factory)); 
} 


} 
this.aspectBeanNames = aspectNames; 


return advisors; 


} 
if (aspectNames.isEmpty()) ( 


return Collections.EMPTY LIST; 


j 
/记录 在 缓存 中 
List<Advisor> advisors = new LinkedList<Advisor>(); 
for (String aspectName : aspectNames) { 
List<Advisor> cachedAdvisors = 
this.advisorsCache.get(aspectName); 
if (cachedAdvisors != null) { 
advisors.addAll(cachedA dvisors); 
j 
else { 
MetadataAwareAspectInstanceFactory factory = 
this.aspectFactoryCache. 
get(aspectName); 
advisors.addAll(this.advisorFactory.getA dvisors(factory)); 


j 
return advisors; 
} 
至 此 ， 我 们 已 经 完成 了 Advisor 的 提取 ， 在 上 面 的 步骤 中 最 为 重要 
也 最 为 繁杂 的 就 是 增强 器 的 获取 。 而 这 一 功能 委托 给 了 getAdvisors 方 
法 去 实现 (this.advisorFactory.getAdvisors(factory)) 。 
public List<Advisor> 
getAdvisors(MetadataAwareAspectInstanceFactory maaif) { 
/获取 标记 为 AspectJ 的 类 
final Class<?> aspectClass = 
maaif.getAspectMetadata().getAspectClass(); 
/获取 标记 为 AspectJ 的 name 


final String aspectName = 
maaif.getAspectMetadata().getAspectName(); 
/验证 
validate(aspectClass); 
final MetadataAwareAspectInstanceFactory 
lazySingletonAspectInstanceFactory 
-new LazySingletonAspectInstanceFactoryDecorator(maaif); 
final List<Advisor> advisors = new LinkedList<Advisor>(); 
ReflectionUtils.doWithMethods(aspectClass, new 
ReflectionUtils. MethodCallback() 1 
public void doWith(Method method) throws 
IllegalArgumentException 1 
/声明 为 Pointcut 的 方法 不 处 理 
if (AnnotationUtils.getAnnotation(method, Pointcut.class) == 
null) { 
Advisor advisor = getAdvisor(method, 
lazySingletonAspectInstance 
Factory, advisors.size(), aspectName); 
if (advisor != null) { 


advisors.add(advisor); 


i 
}); 
if (ladvisors.isEmpty() && 
lazySingletonAspectInstanceFactory.getAspect 
Metadata().isLazilyInstantiated()) { 


/如 果 寻 找 的 增强 器 不 为 空 而 且 又 配置 了 增强 延迟 初始 化 那 
么 需要 在 首位 加 入 同步 实例 化 增强 器 
Advisor instantiationAdvisor = new 
SyntheticInstantiationAdvisor (lazySingleton 
AspectInstanceFactory); 
advisors.add(0, instantiationA dvisor); 
j 
/获取 DeclareParents 注 解 
for (Field field : aspectClass.getDeclaredFields()) 1 
Advisor advisor = getDeclareParentsAdvisor(field); 
if (advisor != null) { 


advisors.add(advisor); 


j 
return advisors; 
j 
函数 中 首先 完成 了 对 增强 器 的 获取 ， 包 括 获 取 注 解 以 及 根据 注解 
生成 增强 的 步骤 ， 然 后 考虑 到 在 配置 中 可 能 会 将 增强 配置 成 延迟 初始 
化 ， 那 么 需要 在 首位 加 入 同步 实例 化 增强 器 以 保证 增强 使 用 之 前 的 实 
例 化 ， 最 后 是 对 DeclareParents 注 解 的 获取 ， 下 面 将 详细 介绍 一 下 每 个 
步骤 。 
1. 普通 增强 器 的 获取 
普通 增强 器 的 获取 逻辑 通过 getAdvisor 方 法 实现 ， 实 现 步骤 包括 对 
切 点 的 注解 的 获取 以 及 根据 注解 信息 生成 增强 。 
public Advisor getAdvisor(Method candidateAdviceMethod, 
MetadataAwareAspectInstanceFactory aif, 


int declarationOrderInAspect, String aspectName) { 


validate(aif.getAspectMetadata().getAspectClass()); 
// 切 点 信息 的 获取 
AspectJExpressionPointcut ajexp = 
getPointcut(candidateAdviceMethod, 
aif.getAspectMetadata().getAspectClass()); 
if (ajexp == null) 1 
return null; 
j 
// 根 据 切 点 信息 生成 增强 器 
return new InstantiationModel AwarePointcutAdvisorImpl( 
this, ajexp, aif, candidateAdviceMethod, declarationOrderInAspect, 
aspectName); 
j 
(1) 切 点 信息 的 获取 。 所 谓 获取 切 点 信息 就 是 指定 注解 的 表达 式 
言 息 的 获取 ， 如 @Before("test()")。 
private AspectJExpressionPointcut getPointcut(Method 
candidateAdviceMethod, Class<?> 
candidateAspectClass) { 
// 获 取 方 法 上 的 注解 
AspectJAnnotation<?> aspectJAnnotation = 
AbstractAspectJAdvisorFactory.findAspectJAnnotationOnMethod 
(candidateAdviceMethod); 
if (aspectJAnnotation == null) { 


return null; 


// 使 用 AspectJExpressionPointcut 实 例 封装 获取 的 信息 


AspectJExpressionPointcut ajexp = 


new AspectJExpressionPointcut(candidateAspectClass, new 
String[0], 
new Class[0]); 
/提取 得 到 的 注解 中 的 表达 式 如 : 
//@Pointcut("execution(* *.*test*(..))")FRBSexecution(* *.*test*(..)) 
ajexp.setExpression(aspectJAnnotation.getPointcutExpression()); 
return ajexp; 
j 
protected static AspectJAnnotation 
findAspectJAnnotationOnMethod(Method method) 1 
/设置 敏感 的 注解 类 
Class<? extends Annotation>[] classesToLookFor = new Class[] { 
Before.class, Around.class, After.class, AfterReturning.class, 
AfterThrowing.class, Pointcut.class}; 
for (Class<? extends Annotation> c : classesToLookFor) { 


AspectJAnnotation foundAnnotation = findAnnotation(method, 


C); 
if (foundAnnotation != null) { 
return foundAnnotation; 
j 
j 
return null; 
j 


/获取 指定 方法 上 的 注解 并 使 用 AspecUJAnnotation 封 装 

private static <A extends Annotation» AspectJAnnotation<A> 
findAnnotation(Method method, 

Class<A> toLookFor) 1 


A result = AnnotationUtils.findAnnotation(method, toLookFor); 


if (result != null) 1 

return new AspectJAnnotation«A » (result); 
} 
else { 


return null; 


} 
(2) 根据 切 点 信息 生成 增强 。 所 有 的 增强 都 由 Advisor 的 实现 类 


InstantiationModelAware PointcutAdvisorImp] 统 一 封装 的 。 
public 
InstantiationModelAwarePointcutAdvisorImpl(AspectJAdvisorFactory af, 
AspectJ 
ExpressionPointcut ajexp, 
MetadataAwareAspectInstanceFactory aif, Method method, int 
declarationOrderInAspect, 
String aspectName) 1 
//test() 
this.declaredPointcut = ajexp; 
//public void test.AspectJTest.beforeTest() 
this.method = method; 
this.atAspectJAdvisorFactory = af; 
this.aspectInstanceFactory = aif; 
//0 
this.declarationOrder = declarationOrderInAspect; 
//test.AspectJTest 


this.aspectName = aspectName; 


if (aif.getAspectMetadata().isLazilyInstantiated()) 1 
// Static part of the pointcut is a lazy type. 


Pointcut preInstantiationPointcut = 


Pointcuts.union(aif.getAspectMetadata().getPerClausePointcut(), 
this.declaredPointcut); 

this.pointcut = new 
PerTargetInstantiationModelPointcut(this.declaredPointcut, 

preInstantiationPointcut, aif); 

this.lazy = true; 

jelse { 

// A singleton aspect. 

this.instantiatedAdvice = 
instantiateAdvice(this.declaredPointcut); 

this.pointcut = declaredPointcut; 


this.lazy = false; 


} 

在 封装 过 程 中 只 是 简单 地 将 信息 封装 在 类 的 实例 中 ， 所 有 的 信息 
单纯 地 赋值 ， 在 实例 初始 化 的 过 程 中 还 完成 了 对 于 增强 器 的 初始 化 。 
因为 不 同 的 增强 所 体现 的 逻辑 是 不 同 的 ， 比 如 @Before (“test()”) 5 
@After ("test()") 标签 的 不 同 就 是 增强 器 增强 的 位 置 不 同 ， 所 以 就 需 
要 不 同 的 增强 器 来 完成 不 同 的 逻辑 ， 而 根据 注解 中 的 信息 初始 化 对 应 
的 增强 器 就 是 在 instantiateAdvice 国 数 中 实现 的 。 

private Advice instantiateAdvice(AspectJExpressionPointcut pcut) 1 

return this.atAspectJAdvisorFactory.getA dvice( 


this.method, pcut, this.aspectInstanceFactory, this.declarationOrder, 


this.aspectName); 
j 
public Advice getAdvice(Method candidateA dviceMethod, 
AspectJExpressionPointcut ajexp, 
MetadataAwareAspectInstanceFactory aif, int 
declarationOrderInAspect, 
String aspectName) 1 
Class<?> candidateAspectClass = 
aif.getAspectMetadata().getAspectClass(); 
validate(candidateAspectClass); 
AspectJAnnotation<?> aspectJ Annotation = 
AbstractAspectJAdvisorFactory.findAspectJAnnotationOnMethod 
(candidate 
AdviceMethod); 
if (aspectJAnnotation == null) { 
return null; 
} 
// If we get here, we know we have an AspectJ method. 
// Check that it's an AspectJ-annotated class 
if (!isAspect(candidateAspectClass)) { 
throw new AopConfigException(" Advice must be declared inside 
an aspect type: " + 
"Offending method "" + candidateAdviceMethod + "' in class [" + 
candidateAspectClass.getName() + "J"; 
} 
if (logger.isDebugEnabled()) 1 


logger.debug("Found AspectJ method: " + 
candidateAdviceMethod); 
} 
AbstractAspectJAdvice Spring Advice; 
// 根 据 不 同 的 注解 类 型 封闭 不 同 的 增强 器 
switch (aspectJAnnotation.getAnnotationType()) 1 
case AtBefore: 
SpringAdvice = 
newAspectJMethodBeforeAdvice(candidateAdviceMethod, ajexp, aif); 
break; 
case AtAfter: 
SpringAdvice = 
newAspectJAfterAdvice(candidateAdviceMethod, ajexp, aif); 
break; 
case AtAfterReturning: 
SpringAdvice = 
newAspectJAfterReturningAdvice(candidate AdviceMethod, 
ajexp, aif); 
AfterReturning afterReturningAnnotation = (AfterReturning) 
aspectJAnnotation. 
getAnnotation(); 
if (StringUtils.hasText(afterReturningAnnotation.returning())) 1 


SpringAdvice.setReturningName(afterReturningAnnotation.returning()); 
j 
break; 
case AtAfterThrowing: 


SpringAdvice = new 
AspectJAfterThrowing Advice(candidateAdviceMethod, 

ajexp, aif); 

AfterThrowing afterThrowingAnnotation = (AfterThrowing) 
aspectJ Annotation. 

getAnnotation(); 

if (StringUtils.hasText(afterThrowingAnnotation.throwing())) { 


SpringAdvice.setl'hrowingName(afterThrowingAnnotation.throwing()); 
j 
break; 
case AtAround: 
SpringAdvice = new 
AspectJAroundAdvice(candidateAdviceMethod, ajexp, aif); 
break; 
case AtPointcut: 
if (logger.isDebugEnabled()) { 
logger.debug( Processing pointcut "' + 
candidateA dviceMethod. 
getName() + '"""); 
} 
return null; 
default: 
throw new UnsupportedOperationException( 
"Unsupported advice type on method " + 
candidateA dviceMethod); 
j 


// Now to configure the advice... 
SpringAdvice.setAspectName(aspectName); 
SpringAdvice.setDeclarationOrder(declarationOrderInAspect); 
String[] argNames = 
this.parameterNameDiscoverer.getParameterNames (candidateAdvice 
Method); 
if (argNames != null) { 
SpringAdvice.setArgumentNamesFromString Array(argNames); 
} 
SpringAdvice.calculateArgumentBindings(); 
return SpringAdvice; 
l 
从 函数 中 可 以 看 到 ，Spring 会 根据 不 同 的 注解 生成 不 同 的 增强 
器 ， 例 如 AtBefore 会 对 应 AspectJMethodBeforeAdvice， 而 在 
AspectJMethodBeforeAdvice 中 完成 了 增强 方法 的 逻辑 。 我 们 尝试 分 析 
下 几 个 常用 的 增强 器 实现 。 
MethodBeforeAdviceInterceptoro 
我 们 首先 查看 MethodBeforeAdviceInterceptor 类 的 内 部 实现 。 
public class MethodBeforeAdviceInterceptor implements 
MethodInterceptor, Serializable { 
private MethodBeforeAdvice advice; 
LI 
* Create a new MethodBeforeA dviceInterceptor for the given 
advice. 
* @param advice the MethodBeforeAdvice to wrap 
iD 


public MethodBeforeAdviceInterceptor(MethodBeforeAdvice 
advice) 1 
Assert.notNull(advice, "Advice must not be null"); 
this.advice = advice; 
j 
public Object invoke(MethodInvocation mi) throws Throwable 1 
this.advice.before(mi.getMethod(), mi.getArguments(), 
mi.getThis() ); 


return mi.proceed(); 


j 
其 中 的 属性 MethodBeforeAdvice 代表 着 前 置 增强 的 
AspectJMethodBeforeAdvice， 跟 踪 before 方 法 : 
public void before(Method method, Object[] args, Object target) 
throws Throwable { 
invokeAdviceMethod(getJoinPoint Match(), null, null); 
} 
protected Object invokeAdviceMethod(JoinPointMatch jpMatch, 
Object returnValue, Throwable 
ex) throws Throwable 1 
return 
invokeAdviceMethodWithGivenArgs(argBinding(getJoinPoint(), jpMatch, 
return Value, ex)); 
j 
protected Object invokeAdviceMethodWithGivenArgs(Object[] args) 
throws Throwable 1 


Object[ ] actualArgs = args; 


if (this.aspectJAdviceMethod.getParameterTypes().length == 0) { 
actualArgs - null; 
j 
try { 
ReflectionUtils.makeA ccessible(this.aspectJAdviceMethod); 
/激活 增强 方法 
return 
this.aspectJ AdviceMethod.invoke(this.aspectInstanceFactory. getAspect 
Instance(), actualArgs); 
} 
catch (IllegalArgumentException ex) 1 
throw new AopInvocationException(" Mismatch on arguments to 
advice method [" + 
this.aspectJAdviceMethod + "]; pointcut expression [" + 
this.pointcut.getPointcutExpression() + "|", ex); 
} 
catch (InvocationTargetException ex) { 


throw ex.getTargetException(); 


} 

invokeAdviceMethodWithGivenArgs 方 法 中 的 aspecUJAdviceMethod 
正 是 对 于 前 置 增强 的 方法 ， 在 这 里 实现 了 调用 。 

AspectJAfterAdviceo 

后 置 增强 与 前 置 增强 有 稍 许 不 一 致 的 地 方 。 回 顾 之 前 讲 过 的 前 置 
增强 ， 大 致 的 结构 是 在 拦截 器 链 中 放置 
MethodBeforeAdviceInterceptor， 而 在 MethodBeforeAdviceInterceptor 中 
又 放置 了 AspectJMethodBeforeAdvice， 并 在 调用 invoke 时 首先 串联 调 


用 。 但 是 在 后 置 增强 的 时 候 却 不 一 样 ， 没 有 提供 中 间 的 类 ， 而 是 直接 
在 拦截 器 链 中 使 用 了 中 间 的 AspectJAfterAdvice。 
public class AspectJAfterAdvice extends AbstractAspectJAdvice 
implements MethodInterceptor, 
AfterAdvice { 
public AspectJAfterAdvice( 
Method aspectJBeforeAdviceMethod, 
AspectJExpressionPointcut pointcut, 
AspectInstanceFactory aif) ( 
super(aspectJBeforeAdviceMethod, pointcut, aif); 
j 
public Object invoke(MethodInvocation mi) throws Throwable 1 
try { 
return mi.proceed(); 
j 
finally { 
/激活 增强 方法 
invokeAdviceMethod(getJoinPointMatch(), null, null); 


j 

public boolean isBeforeAdvice() { 
return false; 

l 

public boolean isAfterAdvice() { 


return true; 


2. 增加 同步 实例 化 增强 器 
如 果 寻 找 的 增强 器 不 为 空 而 且 又 配置 了 增强 延迟 初始 化 ， 那 么 融 
需要 在 首位 加 入 同步 实例 化 增强 器 。 同 步 实 例 化 增强 器 
SyntheticInstantiationAdvisor 如 下 : 
protected static class SyntheticInstantiationAdvisor extends 
DefaultPointcutAdvisor { 
public SyntheticInstantiationAdvisor(final 
MetadataAwareAspectInstanceFactory aif) { 
super(aif.getAspectMetadata().getPerClausePointcut(), new 
MethodBeforeAdvice() { 
/目标 方法 前 调用 ， 类 似 @Before 
public void before(Method method, Object[] args, Object 


target) 1 
/简单 初始 化 aspect 
aif.getAspectInstance(); 
j 
y 
j 
j 


3. XkHXDeclareParents;tf$£ 
DeclareParents 主 要 用 于 引 介 增强 的 注解 形式 的 实现 ， m= CHA 
式 与 普通 增强 很 类 似 ， 只 不 过 使 用 DeclareParentsAdvisor 对 功能 进行 封 
Fo 
private Advisor getDeclareParentsAdvisor(Field introductionField) { 
DeclareParents declareParents = (DeclareParents) 
introductionField.getAnnotation 


(DeclareParents.class); 


if (declareParents == null) { 
// Not an introduction field 
return null; 
J 
if (DeclareParents.class.equals(declareParents.defaultImpl())) 1 
// This is what comes back if it wasn't set. This seems bizarre... 
// TODO this restriction possibly should be relaxed 
throw new IllegalStateException("defaultImpl must be set on 
Declare 
Parents"); 
j 
return new DeclareParentsAdvisor( 
introductionField.getType(), declareParents.value(), declareParents. 
defaultImpl()); 
j 
7.3.2 寻找 匹配 的 增强 器 
前 面 的 国 数 中 已 经 完成 了 所 有 增强 器 的 解析 ， 但 是 对 于 所 有 增强 
器 来 讲 ， 并 不 一 定 都 适用 于 当前 的 Bean， 还 要 挑 取出 适合 的 增强 器 ， 
也 就 是 满足 我 们 配置 的 通配符 的 增强 器 。 具 体 实 现在 
findAdvisorsThatCanApply 中 。 
protected List<Advisor> findAdvisorsThatCanApply( 


List<Advisor> candidateA dvisors, Class beanClass, String beanName) 


ProxyCreationContext.setCurrentProxiedBeanName(beanName); 
try { 
// 过 渡 已 经 得 到 的 advisors 


return AopUtils.findAdvisorsThatCanA pply(candidateA dvisors, 
beanClass); 
j 
finally { 


ProxyCreationContext.setCurrentProxiedBeanName(null); 


j 
Z5: findAdvisorsThatCanA pply : 
public static List<Advisor> 
findAdvisorsThatCanApply(List<Advisor> candidateAdvisors, 
Class<?> clazz) { 
if (candidateAdvisors.isEmpty()) { 
return candidate Advisors; 
} 
List<Advisor> eligibleAdvisors = new LinkedList<Advisor>(); 
/首先 处 理 引 介 增 强 
for (Advisor candidate : candidateAdvisors) { 
if (candidate instanceof IntroductionAdvisor && 
canApply(candidate, clazz)) 1 
eligibleAdvisors.add(candidate); 


j 
boolean hasIntroductions = !eligibleAdvisors.isEmpty(); 
for (Advisor candidate : candidateAdvisors) ( 

/5 引 介 增强 已 经 处 理 

if (candidate instanceof IntroductionAdvisor) { 


continue; 


j 

/对 于 普通 bean 的 处 理 

让 (canApply(candidate, clazz, hasIntroductions)) { 
eligibleAdvisors.add(candidate); 


j 
return eligibleAdvisors; 
j 
findAdvisorsThatCanApply 图 数 的 主要 功能 是 寻找 所 有 增强 器 中 适 
用 于 当前 class 的 增强 器 。 引 介 增 强 与 普通 的 增强 是 处 理 不 一 样 的 ， 所 
以 分 开 处 理 。 而 对 于 真正 的 匹配 在 canApply 中 实现 。 
public static boolean canApply(Advisor advisor, Class<?> targetClass, 
boolean 
hasIntroductions) 1 
if (advisor instanceof IntroductionAdvisor) 1 
return ((IntroductionAdvisor) advisor).getClassFilter().matches 
(targetClass); 
Jelse if (advisor instanceof PointcutAdvisor) { 
PointcutAdvisor pca = (PointcutAdvisor) advisor; 
return canApply(pca.getPointcut(), targetClass, 
hasIntroductions); 
jelse { 
// It doesn't have a pointcut so we assume it applies. 


return true; 


public static boolean canApply(Pointcut pc, Class<?> targetClass, 
boolean hasIntroductions) 1 
Assert.notNull(pc, "Pointcut must not be null"); 
if (!*pc.getClassFilter().matches(targetClass)) 1 
return false; 
j 
MethodMatcher methodMatcher = pc.getMethodMatcher(); 
IntroductionAwareMethodMatcher 
introductionAwareMethodMatcher = null; 
if (methodMatcher instanceof IntroductionAwareMethodMatcher) 1 
introductionAwareMethodMatcher = 
(IntroductionAwareMethodMatcher) methodMatcher; 
Set<Class> classes = new HashSet<Class> 
(ClassUtils.getAllInterfacesForClassAsSet 
(targetClass)); 
classes.add(targetClass); 
//classes:[interface test.ITTestBean, class test. TestBean] 
for (Class<?> clazz : classes) 1 
Method[] methods = clazz.getMethods(); 
for (Method method : methods) 1 
if ((introductionAwareMethodMatcher != null && 
introductionAwareMethodMatcher.matches(method, 
targetClass, 
hasIntroductions)) || 
methodMatcher.matches(method, targetClass)) 1 


return true; 


} 


return false; 


} 


7.3.3 创建 代理 


在 获取 了 所 有 对 应 bean 的 增强 器 后 ， 便 可 以 进行 代理 的 创建 了 。 

protected Object createProxy( 

Class<?> beanClass, String beanName, Object[] specificInterceptors, 
TargetSource 

targetSource) 1 

ProxyFactory proxyFactory = new ProxyFactory(); 
/获取 当前 类 中 相 天 属性 
proxyFactory.copy From(this); 
/决定 对 于 给 定 的 bean 是 否 应 该 使 用 targetClass 而 不 是 他 的 接口 
代理 ， 
// 检 查 proxyTargeClass 设 置 以 及 preserveTargetClass 属 性 
if (!shouldProxyTargetClass(beanClass, beanName)) { 
// Must allow for introductions; can't just set interfaces to 
// the target's interfaces only. 

Class<?>[] targetInterfaces = 
ClassUtils.getAllInterfacesForClass(beanClass,&nbsp;this.proxyClassLoad 
er); 

for (Class<?> targetInterface : targetInterfaces) { 
/添加 代理 接口 


proxyFactory.addInterface(targetInterface); 


} 
Advisor[] advisors = buildAdvisors(beanName, 
specificInterceptors); 
for (Advisor advisor : advisors) { 
/加 入 增强 器 
proxyFactory.addA dvisor(advisor); 
} 
/设置 要 代理 的 类 
proxyFactory.setTargetSource(targetSource); 
/定制 代理 
customizeProxyFactory(proxyFactory); 
/用 来 控制 代理 工厂 被 配置 之 后 ， 是 否 还 允许 修改 通知 。 
// 缺 省 值 为 false ( 即 在 代理 被 配置 之 后 ， 不 允许 修改 代理 的 配 
B) o 
proxyFactory.setFrozen(this.freezeProxy); 
if (advisorsPreFiltered()) { 
proxyFactory.setPreFiltered(true); 
} 
return proxyFactory.getProxy(this.proxyClassLoader); 
} 
对 于 代理 类 的 创建 及 处 理 ，Spring 委 托 给 了 ProxyFactory 去 处 理 ， 
而 在 此 函数 中 主要 是 对 ProxyFactory 的 初始 化 操作 ， 进 而 对 真正 的 创建 
代理 做 准备 ， 这 些 初 始 化 操作 包括 如 下 内 容 。 
(1) 获取 当前 类 中 的 属性 。 
(2) 添加 代理 接口 。 
(3) 封装 Advisor 并 加 入 到 ProxyFactory 中 。 


(4) 设置 要 代理 的 类 。 

(5) 当然 在 Spring 中 还 为 子 类 提供 了 定制 的 函数 
customizeProxyFactory， 子 类 可 以 在 此 函数 中 进行 对 ProxyFactory 的 进 
一 步 封装 。 

(6) 进行 获取 代理 操作 。 

其 中 ， 封 装 Advisor 并 加 入 到 ProxyFactory 中 以 及 创建 代理 是 两 个 
相对 繁琐 的 过 程 ， 可 以 通过 ProxyFactory 提 供 的 addAdvisor 方 法 直接 将 
增强 器 置 入 代理 创建 工厂 中 ， 但 是 将 拦截 器 封装 为 增强 器 还 是 需要 一 
定 的 逻辑 的 。 

protected Advisor[] buildAdvisors(String beanName, Object[j 
specificInterceptors) { 

// 解 析 注 册 的 所 有 interceptorName 

Advisor[] commonInterceptors = resolveInterceptorNames(); 

List<Object> allInterceptors = new ArrayList<Object>(); 

if (specificInterceptors != null) { 

/加 入 拦截 器 
allInterceptors.addAll(Arrays.asList(specificInterceptors)); 
if (commonInterceptors != null) { 
if (this.applyCommonInterceptorsFirst) 1 
allInterceptors.addAIl(0, 
Arrays.asList(commonlInterceptors)); 
j 


else { 


allInterceptors.addAll( Arrays.asList(commonlnterceptors)); 


if (logger.isDebugEnabled()) 1 
int nrOfCommonlInterceptors = (commoniInterceptors !- null ? 
commoniInterceptors. 
length : 0); 
int nrOfSpecificInterceptors = (specificInterceptors != null ? 
specificInterceptors. 
length : 0); 
logger.debug(" Creating implicit proxy for bean " + beanName + 
" with " + 
nrOfCommoniInterceptors + 
" common interceptors and " + nrOfSpecificInterceptors + " 
specific 
interceptors"); 
j 
Advisor[] advisors = new Advisor[allInterceptors.size()]; 
for (int i = 0; i < allInterceptors.size(); i++) 1 
// ASH THA Advisor 
advisors[i] = 
this.advisorAdapterRegistry.wrap(allInterceptors.get(1)); 
j 
return advisors; 
j 
public Advisor wrap(Object adviceObject) throws 
UnknownAdviceTypeException { 
/如 果 要 封装 的 对 象 本 身 就 是 Advisor 类 型 的 那么 无 需 再 做 过 多 
处 理 


if (adviceObject instanceof Advisor) 1 


return (Advisor) adviceObject; 
j 
/因为 此 封装 方法 只 对 Advisor 与 Advice 两 种 类 型 的 数据 有 效 ， 
如 果 不 是 将 不 能 封装 
if (!(adviceObject instanceof Advice)) { 
throw new UnknownAdviceTypeException(adviceObject); 
i 
Advice advice = (Advice) adviceObject; 
if (advice instanceof MethodInterceptor) { 
/如 果 是 MethodInterceptor 类 型 则 使 用 DefaultPointcutAdvisor 
封装 
return new DefaultPointcutAdvisor(advice); 
j 
// 如 果 存 在 Advisor 的 适配器 那么 也 同样 需要 进行 封闭 
for (AdvisorAdapter adapter : this.adapters) { 
// Check that it is supported. 
if (adapter.supportsAdvice(advice)) { 


return new DefaultPointcutAdvisor(advice); 


} 
throw new UnknownAdviceTypeException(advice); 
j 
由 于 Spring 中 涉及 过 多 的 拦截 器 、 增 强 器 、 增 强 方法 等 方式 来 对 
逻辑 进行 增强 ， 所 以 非常 有 必要 统一 封装 成 Advisor 来 进行 代理 的 创 
建 ， 完 成 了 增强 的 封装 过 程 ， 那 么 解析 最 重要 的 一 步 就 是 代理 的 创建 
与 获取 了 。 
public Object getProxy(ClassLoader classLoader) { 


return createAopProxy().getProxy(classLoader); 
j 
1. 创建 代理 
protected final synchronized AopProxy createAopProxy() 1 
if (!this.active) { 
activate(); 
i 
/创建 代理 
return getAopProxyFactory().create AopProxy(this); 
j 
public AopProxy createAopProxy(AdvisedSupport config) throws 
AopConfigException 1 
if (config.isOptimize() || config.isProxyTargetClass() || 
hasNoUserSuppliedProxy 
Interfaces(config)) { 
Class targetClass = config.getTargetClass(); 
if (targetClass == null) { 
throw new AopConfigException("TargetSource cannot 
determine target class: " + 
"Either an interface or a target is required for proxy 
creation."); 
} 
if (targetClass.isInterface()) { 
return new JdkDynamicAopProxy(config); 
} 
if (!IcglibAvailable) { 


throw new AopConfigException( 


"Cannot proxy target class because CGLIB2 is not 
available. "+ 
"Add CGLIB to the class path or specify proxy interfaces."); 
j 
return CglibProxyFactory.createCglibProxy(config); 
j 
else { 


return new JdkDynamicAopProxy(config); 


} 

到 此 已 经 完成 了 代理 的 创建 ， 不 管 我 们 之 前 是 否 有 阅读 过 Spring 
的 源 代 码 ， 但 是 都 或 多 或 少 地 听 过 对 于 Spring 的 代理 中 JDKProxy 的 实 
现 和 CglibProxy 的 实现 。Spring 是 如 何 选取 的 呢 ? 网 上 的 介绍 到 处 都 
是 ， 现 在 我 们 就 从 源 代码 的 角度 分 析 ， 看 看 到 底 Spring 是 如 何 选择 代 
理 方 式 的 。 

从 if 中 的 判断 条 件 可 以 看 到 3 个 方面 影响 着 Spring 的 判断 。 

optimize: 用 来 控制 通过 CGLIB 创 建 的 代理 是 否 使 用 激进 的 优化 策 
略 。 除 非 完全 了 解 AOP 代 理 如何 处 理 优 化 ， 否 则 不 推荐 用 户 使 用 这 个 
设置 。 目 前 这 个 属性 仅 用 于 CGLIB 代 理 ， 对 于 JDK 动 态 代 理 (MAR 
理 ) 无 效 。 

proxyTargetClass: 这 个 属性 为 true 时 ， 目 标 类 本 身 被 代理 而 不 是 
目标 类 的 接口 。 如 果 这 个 属性 值 被 设 为 true，CGLIB 代理 将 被 创建 ， 
设置 方式 : <aop:aspectj-autoproxy proxy-target-class="true"/>o 

hasNoUserSuppliedProxyInterfaces: 是 否 存在 代理 接口 。 

下 面 是 对 JDK 与 Cglib 方 式 的 总 结 。 

如 果 目 标 对 象 实现 了 接口 ， 默 认 情 况 下 会 采用 JDK 的 动态 代理 实 
现 AOP。 


如 果 目 标 对 象 实现 了 接口 ， 可 以 强制 使 用 CGLIB 实 现 AOP。 
如 果 目 标 对 象 没有 实现 了 接口 ， 必 须 采 用 CGLIB 库 ，Spring 会 自 
动 在 JDK 动 态 代理 和 CGLIB 之 间 转 换 。 
如 何 强制 使 用 CGLIB 实 现 AOP? 
(1) 添加 CGLIB 库 ，Spring_HOME/cglib/*.jaro 
(2) 在 Spring 配 置 文 件 中 加 入 <aop:aspectj-autoproxy proxy-target- 
class="true"/>o 
JDK 动 态 代理 和 CGLIB 字 节 码 生成 的 区 别 ? 
JDK 动 态 代理 只 能 对 实现 了 接口 的 类 生成 代理 ， 而 不 能 针对 类 。 
CGLIB 是 针对 类 实现 代理 ， 主 要 是 对 指定 的 类 生成 一 个 子 类 ， 覆 
盖 其 中 的 方法 ， 因 为 是 继承 ， 所 以 该 类 或 方法 最 好 不 要 声明 成 final。 
2. 获取 代理 
确定 了 使 用 哪 种 代理 方式 后 便 可 以 进行 代理 的 创建 了 ， 但 是 创建 
之 前 有 必要 回顾 一 下 两 种 方式 的 使 用 方法 。 
(1) JDK 代 理 使 用 示例 。 
创建 业务 接口 ， 业 务 对 外 提供 的 接口 ， 包 含 着 业务 可 以 对 外 提供 
的 功能 。 
public interface UserService { 
LI 
* 目标 方法 
si 
public abstract void add(); 
} 
创建 业务 接口 实现 类 。 
public class UserServiceImpl implements UserService { 
/* (non-Javadoc) 


* @see dynamic.proxy.UserService#add() 


e 
public void add() 1 


System.out.println(" 


j 
创建 自 定 义 的 InvocationHandler， 用 于 对 接口 提供 的 方法 进行 增 


DE 


public class MyInvocationHandler implements InvocationHandler { 


/ 目标 对 象 

private Object target; 

[** 
* 构造 方法 
* @param target 目 标 对 象 
*/ 

public MyInvocationHandler(Object target) { 
super(); 
this.target — target; 


fe 
* 执行 目标 对 象 的 方法 
2 
public Object invoke(Object proxy, Method method, Object[] args) 
throws Throwable 1 
/ 在 目标 对 象 的 方法 执行 之 前 简单 的 打印 一 下 
System.out.println(" 
/ 执行 目标 对 象 的 方法 


Object result = method.invoke(target, args); 


/ 在 目标 对 象 的 方法 执行 之 后 简单 的 打印 一 下 
System.out.println(" ------------------- after------------------ ee 
return result; 
} 
LI 
* 获取 目标 对 象 的 代理 对 象 
* (return 代 理 对 象 
*/ 
public Object getProxy() { 
return 
Proxy.newProxyInstance(Thread.currentThread().getContextClassLoader(), 


target.getClass().getInterfaces(), this); 


} 
最 后 进行 测试 ， 验 证 对 于 接口 的 增强 是 否 起 到 作用 。 
public class ProxyTest { 
@Test 
public void testProxy() throws Throwable { 
/ 实例 化 目标 对 象 
UserService userService = new UserServiceImpl(); 
/ 实例 化 InvocationHandler 
MyInvocationHandler invocationHandler = new 
MyInvocationHandler(userService); 
/ 根据 目标 对 象 生成 代理 对 象 
UserService proxy = (UserService) 


invocationHandler.getProxy(); 


/ 调用 代理 对 象 的 方法 


proxy.add(); 


} 
} 
执行 结果 如 下 : 
------------------ before------------- 
-------------------- add-------------- 
------------------- after-------------- 


用 起 来 很 简单 ， 其 实 这 基本 上 就 是 AOP 的 一 个 简单 实现 了 ， 在 目 
标 对 象 的 方法 执行 之 前 和 执行 之 后 进行 了 增强 。Spring 的 AOP 实 现 其 
实 也 是 用 了 Proxy 和 InvocationHandler 这 两 个 东西 的 。 

我 们 再 次 来 回顾 一 下 使 用 JDK 代理 的 方式 ， 在 整个 创建 过 程 中 ， 
对 于 InvocationHandler 的 创建 是 最 为 核心 的 ， 在 自 定义 的 
InvocationHandler- P# #253 RR. 

构造 水 数 ， 将 代理 的 对 象 传 入 。 

invoke 方 法 ， 此 方法 中 实现 了 AOP 增 强 的 所 有 逻辑 。 

getProxy 方 法 ， 此 方法 千篇一律 ， 但 是 必 不 可 少 。 

那么 ， 我 们 看 看 Spring 中 的 JDK 代 理 实现 是 不 是 也 是 这 么 做 的 呢 ? 
继续 之 前 的 跟踪 ， 到 达 JdkDynamicAopProxy 的 getProxyo 

public Object getProxy(ClassLoader classLoader) { 

if (logger.isDebugEnabled()) { 
logger.debug(" Creating JDK dynamic proxy: target source is " + 
this. 
advised.getTargetSource()); 
j 
Class[] proxiedInterfaces = 
AopProxyUtils.completeProxiedInterfaces(this.advised); 
findDefinedEqualsAndHashCodeMethods(proxiedInterfaces); 


return Proxy.newProxyInstance(classLoader, proxiedInterfaces, 
this); 
j 
通过 之 前 的 示例 我 们 知道 ，JDKProxy 的 使 用 关键 是 创建 自 定 义 的 
InvocationHandler， 而 InvocationHandler FES f $5 £878 ss BJ RX 
getProxy， 而 当前 的 方法 正 是 完成 了 这 个 操作 。 再 次 确认 一 下 
JdkDynamicAopProxy 也 确实 实现 了 InvocationHandler 接 口 ， 那 么 我 们 
就 可 以 推断 出 ， 在 JdkDynamicAopProxy 中 一 定 会 有 个 invoke 国 数 ， 并 
且 JdkDynamicAopProxy 会 把 AOP 的 核心 逻辑 写 在 其 中 。 查 看 代码 ， 果 
然 有 这 样 个 函数 : 
public Object invoke(Object proxy, Method method, Object[] args) 
throws Throwable 1 
MethodInvocation invocation; 
Object oldProxy = null; 
boolean setProxyContext = false; 
TargetSource targetSource = this.advised.targetSource; 
Class targetClass = null; 
Object target = null; 
try { 
//equals 方 法 的 处 理 
if (!this.equalsDefined && AopUtils.isEqualsMethod(method)) { 
return equals(args[0]); 
/hash 方 法 的 处 理 
if (!this.hashCodeDefined && 
AopUtils.isHashCodeMethod(method)) { 
return hashCode(); 


j 
/* 
* Class 类 的 isAssignableFrom(Class cls) 方 法 : 
* 如 果 调 用 这 个 方法 的 class 或 接口 与 参数 cls 表 示 的 类 或 接口 
相同 ， 
* 或 者 是 参数 cls 表 示 的 类 或 接口 的 父 类 ， 则 返回 trueo 
* 形象 地 : 自身 类 .class.isAssignableFrom( 自 身 类 或 子 类 .class) 
返回 true 
epi 
* 
System.out.printIn(ArrayList.class.isAssignableFrom(Object.class)); 
//false 
* 
System.out.printIn(Object.class.isAssignableFrom(ArrayList.class)); 
//true 
*/ 
if (!this.advised.opaque && method.getDeclaringClass().isInterface() 
&& method.getDeclaringClass().isAssignableFrom(Advised.class)) 1 
return AopUtils.invokeJoinpointUsingReflection(this.advised, 
method, args); 
j 
Object ret Val; 
/有 时 候 目 标 对 象 内 部 的 自我 调用 将 无 法 实施 切面 中 的 增强 则 
需要 通过 此 属性 暴露 代理 
if (this.advised.exposeProxy) { 
oldProxy = AopContext.setCurrentProxy(proxy); 


setProxyContext = true; 


j 
target = targetSource.getTarget(); 
if (target != null) { 
targetClass = target.getClass(); 
} 
/获取 当前 方法 的 拦截 器 链 
List<Object> chain = 
this.advised.getInterceptorsAndDynamicInterceptionAdvice 
(method, targetClass); 
if (chain.isEmpty()) 1 
/如 果 没 有 发 现任 何 拦截 器 那么 直接 调用 切 点 方法 
retVal = AopUtils.invokeJoinpointUsingReflection(target, 
method, args); 
jelse { 
// 将 拦截 器 封装 在 ReflectiveMethodInvocation， 
/以 便于 使 用 其 proceed 进 行 链接 表 用 拦截 器 
invocation = new ReflectiveMethodInvocation(proxy, target, 
method, 
args, targetClass, chain); 
/执行 拦截 器 链 


retVal = invocation.proceed(); 


/返回 结果 

if (retVal != null && retVal == target && 
method.getReturnType(). IsInstance 

(proxy) && 


'RawTargetAccess.class.isAssignableFrom(method.getDeclaringClass())) 1 
retVal = proxy; 
j 
return ret Val; 
} 
finally { 
if (target != null && !targetSource.isStatic()) 1 
// Must have come from TargetSource. 
targetSource.releaseTarget(target); 
j 
if (setProxyContext) 1 
// Restore old proxy. 
AopContext.setCurrentProxy(oldProxy); 


j 

LANAA Pas PAY Pace Be TNR, AER 
ReflectiveMethodInvocation 类 进行 了 链 的 封装 ， 而 在 
ReflectiveMethodInvocation 类 的 proceed 方 法 中 实现 了 拦截 器 的 逐一 调 
用 ， 那 么 我 们 继续 来 探究 ， 在 proceed 方 法 中 是 怎么 实现 前 置 增强 在 目 
标 方法 前 调用 后 置 增强 在 目标 方法 后 调用 的 逻辑 呢 ? 

if (this.currentInterceptorIndex == 

this.interceptors AndDynamicMethodMatchers. 

public Object proceed() throws Throwable { 

// 执行 完 所 有 增强 后 执行 切 点 方法 
size() - 1) 1 


return invokeJoinpoint(); 
j 
/获取 下 一 个 要 执行 的 拦截 器 


Object interceptorOrInterceptionAdvice = 


this.interceptorsAndDynamicMethodMatchers.get(++this.currentInterceptor 
Index); 
if (interceptorOrInterceptionAdvice instanceof 
InterceptorAndDynamicMethodMatcher) { 
/动态 匹配 ， 
InterceptorAndDynamicMethodMatcher dm = 
(InterceptorAndDynamicMethodMatcher) 
interceptorOrInterceptionAdvice; 
if (dm.methodMatcher.matches(this.method, this.targetClass, 
this.arguments)) { 
return dm.interceptor.invoke(this); 
jelse { 
/不 匹配 则 不 执行 拦截 器 
return proceed(); 
j 
jelse { 
[FEBR ÉNSR, BRA ees, EDAD: 
* ExposelnvocationInterceptor, 
* DelegatePerTargetObjectIntroductionInterceptor, 
* MethodBeforeAdvicelnterceptor 
* AspectJ AroundAdvice, 
* AspectJAfterAdvice 


i 
/将 this 作 为 参数 传递 以 保证 当前 实例 中 调用 链 的 执行 
return ((MethodInterceptor) 
interceptorOrInterceptionA dvice).invoke(this); 
} 

} 

在 proceed 方 法 中 ， 或 许 代 码 逻 辑 并 没有 我 们 想象 得 那么 复杂 ， 
ReflectiveMethodInvocation 中 的 主要 职责 是 维护 了 链接 调用 的 计数 器 ， 
记录 着 当前 调用 链接 的 位 置 ， 以 便 链 可 以 有 序 地 进行 下 去 ， 那 么 在 这 
个 方法 中 并 没有 我 们 之 前 设想 的 维护 各 种 增强 的 顺序 ， 而 是 将 此 工作 
委托 给 了 各 个 增强 器 ， 使 各 个 增强 器 在 内 部 进行 逻辑 实现 。 

(2) CGLIB 使 用 示例 。 

CGLIB 是 一 个 强大 的 高 性 能 的 代码 生成 包 。 它 广泛 地 被 许多 AOP 
的 框架 使 用 ， 例 如 Spring AOP 和 dynaop， 为 他 们 提供 方法 的 
Interception (拦截 ) 。 最 流行 的 OR Mapping 工 具 Hibernate 也 使 用 
CGLIB 来 代理 单 端 single-ended (多 对 一 和 一 对 一 ) 关联 (对 集合 的 延 
迟 抓 取 是 采用 其 他 机 制 实现 的 ) 。EasyMock 和 jMock 是 通过 使 用 模仿 

(moke) 对 象 来 测试 Java 代 码 的 包 。 它 们 都 通过 使 用 CGLIB 来 为 那些 
没有 接口 的 类 创建 模仿 (moke) 对 象 。 

CGLIB 包 的 底层 通过 使 用 一 个 小 而 快 的 字 节 码 处 理 框 架 ASM， 来 
转换 字 节 码 并 生成 新 的 类 。 除 了 CGLIB 包 ， 脚 本 语言 例如 Groovy 和 
BeanShell， 也 是 使 用 ASM 来 生成 Java 的 字 节 码 。 当 然 不 鼓励 直接 使 用 
ASM， 因 为 它 要 求 你 必须 对 JVM 内 部 结构 包括 class 文 件 的 格式 和 指令 
集 都 很 熟悉 。 

我 们 先 快 速 地 了 解 CGLIB 的 使 用 示例 。 

import java.lang.reflect. Method; 


import net.sf.cglib.proxy.Enhancer; 


import net.sf.cglib.proxy.MethodInterceptor; 
import net.sf.cglib.proxy.MethodProxy; 
public class EnhancerDemo 1 
public static void main(String[] args) 1 
Enhancer enhancer = new Enhancer(); 
enhancer.setSuperclass(EnhancerDemo.class); 
enhancer.setCallback(new MethodInterceptorImpl()); 


EnhancerDemo demo = (EnhancerDemo) enhancer.create(); 
demo.test(); 


System.out.printIn(demo); 


} 
public void test() { 


System.out.printIn("EnhancerDemo test()"); 


} 


private static class MethodInterceptorImpl implements 
MethodInterceptor 1 


@Override 


public Object intercept(Object obj, Method method, Object[] 

args, 

MethodProxy proxy) throws Throwable { 
System.err.println(" Before invoke " + method); 
Object result = proxy.invokeSuper(obj, args); 


System.err.println(" After invoke" + method); 
return result; 


运行 结果 如 下 : 
Before invoke public void EnhancerDemo.test() 
EnhancerDemo test() 
After invokepublic void EnhancerDemo.test() 
Before invoke public java.lang.String java.lang.Object.toString() 
Before invoke public native int java.lang.Object.hashCode() 
After invokepublic native int java.lang.Object.hashCode() 
After invokepublic java.lang.String java.lang.Object.toString() 
EnhancerDemo$$EnhancerByCGLIB$$bc9b2066@1621e42 
可 以 看 到 System.out.printIn(demo), demo 首先 调用 了 toString() 方 
法 ， 然 后 又 调用 了 hashCode， 生 成 的 对 象 为 
EnhancerDemo$$EnhancerByCGLIB$$bc9b2066 的 实例 ， 这 个 类 是 运行 
时 由 CGLIB 产 生 的 。 
完成 CGLIB 代 理 的 类 是 委托 给 Cglib2AopProxy 类 去 实现 的 ， 我 们 
进入 这 个 类 一 探究 竟 。 
按照 前 面 提 供 的 示例 ， 我 们 容易 判断 出 来 ，Cglib2AopProxy 的 入 
口 应 该 是 在 getProxy， 也 就 是 说 在 Cglib2AopProxy 类 的 getProxy 方 法 中 
实现 了 Enhancer 的 创建 及 接口 封装 。 
public Object getProxy(ClassLoader classLoader) { 
if (logger.isDebugEnabled()) { 
logger.debug(" Creating CGLIB2 proxy: target source is " + 
this.advised. 
getTargetSource()); 
j 
try { 
Class rootClass = this.advised.getTargetClass(); 


creating 


Assert.state(rootClass != null, "Target class must be available for 


a CGLIB proxy"); 

Class proxySuperClass = rootClass; 

if (ClassUtils.isCglibProxyClass(rootClass)) { 
proxySuperClass = rootClass.getSuperclass(); 
Class[] additionalInterfaces = rootClass.getInterfaces(); 
for (Class additionalInterface : additionalInterfaces) { 


this.advised.addInterface(additional Interface); 


} 
/验证 Class 
validateClassIfNecessary(ProxySuperClass); 
// 创 建 及 配置 Enhancer 
Enhancer enhancer = createEnhancer(); 
if (classLoader != null) { 
enhancer.setClassLoader(classLoader); 
if (classLoader instanceof SmartClassLoader && 
((SmartClassLoader) classLoader).isClassReloadable(proxy 
SuperClass)) 1 
enhancer.setUseCache(false); 


} 


enhancer.setSuperclass(proxySuperClass); 


enhancer.setStrategy(new 


UndeclaredThrowableStrategy(UndeclaredThrowable 


Exception.class)); 


enhancer.setInterfaces( AopProxyUtils.completeProxiedInterfaces(this.advis 


ed)); 
enhancer.setInterceptDuringConstruction(false); 
/设置 拦截 器 
Callback[] callbacks = getCallbacks(rootClass); 
enhancer.setCallbacks(callbacks); 
enhancer.setCallbackFilter(new ProxyCallbackFilter( 
this.advised.getConfigurationOnlyCopy(), 
this.fixedInterceptorMap, 
this.fixedInterceptorOffset)); 
Class[] types = new Class[callbacks.length]; 
for (int x = 0; x < types.length; x++) 1 
types[x] = callbacks[x].getClass(); 
j 
enhancer.setCallback Types(types); 
/生成 代理 类 以 及 创建 代理 
Object proxy; 
if (this.constructorArgs !- null) { 
proxy = enhancer.create(this.constructorArg Types, 


this.constructorArgs); 
j 
else { 
proxy = enhancer.create(); 
j 


return proxy; 


catch (CodeGenerationException ex) 1 
throw new AopConfigException(" Could not generate CGLIB 
subclass of class [" + 
this.advised.getTargetClass() + "]: " + 
"Common causes of this problem include using a final class or a 
non-visible class", 
ex); 
j 
catch (IllegalArgumentException ex) 1 
throw new AopConfigException(" Could not generate CGLIB 
subclass of class [" + 
this.advised.getTargetClass() + "J: " + 
"Common causes of this problem include using a final class or a 
non-visible class", 
eX); 
} 
catch (Exception ex) { 
// TargetSource.getTarget() failed 
throw new AopConfigException("Unexpected AOP exception", 


ex); 


以 上 函数 完整 地 前述 了 一 个 创建 Spring 中 的 Enhancer 的 过 程 ， 读 者 
可 以 参考 Enhancer 的 文档 查看 每 个 步骤 的 含义 ， 这 里 最 重要 的 是 通过 
getCallbacks 方 法 设置 拦截 器 链 。 
private Callback[] getCallbacks(Class rootClass) throws Exception 1 
/对 于 expose-proxy 属 性 的 处 理 


boolean exposeProxy = this.advised.isExposeProxy(); 
boolean isFrozen = this.advised.isFrozen(); 
boolean isStatic = this.advised.getTargetSource().isStatic(); 
/将 拦截 器 封装 在 DynamicAdvisedInterceptor 中 
Callback aopInterceptor = new 
DynamicA dvisedInterceptor(this.advised); 
// Choose a "straight to target" interceptor. (used for calls that are 
// unadvised but can return this). May be required to expose the 
proxy. 
Callback targetInterceptor; 
if (exposeProxy) { 
targetInterceptor = isStatic ? 
new StaticUnadvisedExposedInterceptor 
(this.advised.getTargetSource(). 
getTarget()) : 
new 
DynamicUnadvisedExposedInterceptor(this.advised.getTargetSource()); 
}else { 
targetInterceptor = isStatic ? 
new StaticUnadvisedInterceptor(this.advised.getTargetSource(). 
getTarget()) : 
new 
DynamicUnadvisedInterceptor(this.advised.getTargetSource()); 
} 
// Choose a "direct to target" dispatcher (used for 
// unadvised calls to static targets that cannot return this). 


Callback targetDispatcher = isStatic ? 


new StaticDispatcher(this.advised.getTargetSource().getTarget()) 


new SerializableNoOp(); 
Callback[] mainCallbacks = new Callback[]{ 
/将 拦截 器 链 加 入 Callback 中 


aopInterceptor, 


targetInterceptor, // invoke target without considering advice, if 
optimized 


new SerializableNoOp(), // no override for methods mapped to 
this 
targetDispatcher, this.advisedDispatcher, 
new EqualsInterceptor(this.advised), 
new HashCodelInterceptor(this.advised) 
H 
Callback[] callbacks; 
// Tf the target is a static one and the advice chain is frozen, 
// then we can make some optimisations by sending the AOP calls 
// direct to the target using the fixed chain for that method. 
if (isStatic && isFrozen) { 
Method[] methods = rootClass.getMethods(); 
Callback[] fixedCallbacks = new Callback[methods.length]; 
this.fixedInterceptorMap = new HashMap<String, Integer? 
(methods. length); 
// TODO: small memory optimisation here (can skip creation for 
// methods with no advice) 


for (int x = 0; x < methods.length; x++) { 


List<Object> chain = this.advised.getInterceptorsAndDynamic 
Interception 


Advice(methods[X], rootClass); 


fixedCallbacks[x] = new FixedChainStaticTargetInterceptor( 


chain, this.advised.getTargetSource().getTarget(), this.advised. 
getTargetClass()); 


this.fixedInterceptorMap.put(methods[x ].toString(), x); 
} 


// Now copy both the callbacks from mainCallbacks 

// and fixedCallbacks into the callbacks array. 

callbacks = new Callback[mainCallbacks.length + 
fixedCallbacks.length]; 


System.arraycopy(mainCallbacks, 0, callbacks, 0, 
mainCallbacks.length); 


System.arraycopy(fixedCallbacks, 0, callbacks, 
mainCallbacks.length, 


fixedCallbacks.length); 


this.fixedInterceptorOffset = mainCallbacks.length; 
} 


else { 


callbacks = mainCallbacks; 


} 
return callbacks; 


} 


在 getCallback 中 Spring 考虑 了 很 多 情况 ， 但 是 对 于 我 们 来 说 ， 只 需 
要 理解 最 常用 的 就 可 以 了 ， 比 如 将 advised 属 性 封闭 在 


DynamicAdvisedInterceptor 并 加 入 在 callbacks 中 ， 这 么 做 的 目的 是 什么 


呢 ， 如 何 调用 呢 ? 在 前 面 的 示例 中 ， 我 们 了 解 到 CGLIB 中 对 于 方法 的 
拦截 是 通过 将 自 定义 的 拦截 器 (实现 MethodInterceptor 接 口 ) 加 入 
Callback 中 并 在 调用 代理 时 直接 激活 拦截 器 中 的 intercept 方法 来 实现 
的 ， 那 么 在 getCallback 中 正 是 实现 了 这 样 一 个 目的 ，Dynamic 
AdvisedInterceptor 继 承 自 MethodInterceptor， 加 入 Callback 中 后 ， 在 再 
次 调用 代理 时 会 直接 调用 DynamicAdvisedInterceptor 中 的 intercept 方 
法 ， 由 此 推断 ， 对 于 CGLIB 方 式 实现 的 代理 ， 其 核心 逻辑 必然 在 
DynamicAdvisedInterceptor 中 的 intercept 中 。 
public Object intercept(Object proxy, Method method, Object[] args, 
MethodProxy methodProxy) 
throws Throwable 1 
Object oldProxy = null; 
boolean setProxyContext = false; 
Class targetClass = null; 
Object target = null; 
try { 
if (this.advised.exposeProxy) { 
// Make invocation available if necessary. 
oldProxy = AopContext.setCurrentProxy(proxy); 
setProxyContext = true; 
} 
target = getTarget(); 
if (target != null) { 
targetClass = target.getClass(); 
} 
/获取 拦截 器 链 


List<Object> chain = 
this.advised.getInterceptorsAndDynamicInterceptionAdvice 
(method, targetClass); 
Object ret Val; 
if (chain.isEmpty() && 
Modifier.isPublic(method.getModifiers())) { 
/如 果 拦 截 器 链 为 空 则 直接 激活 原 方法 
retVal = methodProxy.invoke(target, args); 
jelse { 
/进入 链 
retVal = new CglibMethodInvocation(proxy, target, method, 
args, 
targetClass, chain, methodProxy).proceed(); 
j 
retVal = massageReturnTypelfNecessary(proxy, target, method, 
retVal); 
return ret Val; 
} 
finally { 
if (target != null) { 
release Target(target); 
} 
if (setProxyContext) { 
// Restore old proxy. 
AopContext.setCurrentProxy(oldProxy); 


} 

上 述 的 实现 与 JDK 方 式 实 现代 理 中 的 invoke 方 法 大 同 小 异 ， 都 是 
首先 构造 链 ， 然 后 封装 此 链 进 行 串联 调用 ， 稍 有 些 区 别 就 是 在 JDK 中 
直接 构造 ReflectiveMethodInvocation， 而 在 cglib 中 使 用 
CglibMethodInvocation。 CglibMethodInvocation 继承 自 
ReflectiveMethodInvocation， 但 是 proceed 方 法 并 没有 重 写 。 


7.4 AOP zn 


加 载 时 织 入 (Load-Time Weaving, LTW) 指 的 是 在 虚拟 机 载 入 字 
节 码 文件 时 动态 织 入 AspectJ 切 面 。Spring 框 架 的 值 添 加 为 AspectJ LTW 
在 动态 织 入 过 程 中 提供 了 更 细 粒 度 的 控制 。 使 用 Java (5+) 的 代理 能 
使 用 一 个 叫 “Vanilla” 的 Aspect LTW， 这 需要 在 启动 JVM 的 时 候 将 某 个 
JVM 参 数 设 置 为 开 。 这 种 JVM 范 围 的 设置 在 一 些 情况 下 或 许 不 错 ， 但 
通常 情况 下 显得 有 些 粗 颗粒 。 而 用 Spring 的 LTW 能 让 你 在 per- 
ClassLoader 的 基础 上 打开 LTW， 这 显然 更 加 细 粒 度 并 且 对 “ 单 JVM 多 应 
用 ”的 环境 更 具 意义 (例如 在 一 个 典型 应 用 服务 器 环境 中 ) 。 另 外 ,在 
某 些 环 境 下 ， 这 能 让 你 使 用 LTW 而 不 对 应 用 服务 器 的 启动 脚本 做 任何 
改动 ， 不 然则 需要 添加 -javaagent:path/to/aspectjweaver.jar 或 者 (以 下 将 
Ste) -javaagent:path/to/Spring-agent.jar。 开 发 人 员 只 需 简 单 修改 
应 用 上 下 文 的 一 个 或 几 个 文件 就 能 使 用 LTW， 而 不 需 依靠 那些 管理 者 
部 署 配置 ， 比 如 局 动 脚 本 的 系统 管理 员 。 

我 们 还 是 以 之 前 的 AOP 示例 为 基础 ， 如 果 想 从 动态 代理 的 方式 改 
成 静态 代理 的 方式 需要 做 如 下 改动 。 

(1) Spring 全 局 配置 文件 的 修改 ， 加 入 LWT 开 关 。 
<?xml version="1.0" encoding="UTF-8"?> 


«beans xmlns-"http://www.Springframework.org/schema/beans" 


xmins:xsi-"http://www.w3.0rg/2001/XMLSchema-instance" 
xmins:aop-"http://www.Springframework.org/schema/aop" 


xmlns:context="http://www.Springframework.org/schema/context" 


xsi:schemaLocation-"http://www.Springframework.org/schema/beans 
http://www.Springframework.org/schema/beans/Spring- 
beans-3.0.xsd 
http://www.Springframework.org/schema/aop 
http://www. Springframework.org/schema/aop/Spring-aop -3.0.xsd 
http://www.Springframework.org/schema/context http: 
//www.Springframework.org/schema/context/Spring-context- 
3.0.xsd 
pns 
«aop:aspectj-autoproxy /> 
<bean id-"test" class-" test. TestBean"/» 
<bean class="test.AspectJTest"/> 
<context:load-time-weaver /> 
</beans> 
(2) 加 入 aop.xml。 在 class 目 录 下 的 META-INF (没有 则 自己 建 
X) 文件 夹 下 建立 aop.xml， 内 容 如 下 : 
«IDOCTYPE aspectj PUBLIC "-//AspectJ//DTD//EN" 
"http://www.eclipse.org/aspectj/dtd/aspectj.dtd"> 
<aspectj> 
<weaver> 
<!-- only weave classes in our application-specific packages --> 
<include within="test.*" /> 


</weaver> 


«aspects? 
<!-- weave in just this aspect --> 
«aspect name- "test. AspectJ Test" /> 
</aspects> 
</aspectj> 
主要 是 告诉 Aspect 需 要 对 哪个 包 进 行 织 入 ， 并 使 用 哪些 增强 器 。 
(3) 加 入 启动 参数 。 如 果 是 在 Eclipse 中 启动 的 话 需要 加 上 启动 参 
数 ， 如 图 7-3 所 示 。 


© Main |= Arguments » BA JRE Classpath | Bs Source | P Environment) C3 Common | Tracepoint 


Program arguments: 


Varjables... | 


VM arguments: 


-javaagentze:\org.springframework.instrumentjar 


Variables... | 


Working directory: 
© Default: ${workspace_locorg.springtramework.context] 


Other: 


7-3 eclipse 使 用 AspectU 的 配置 


(4) 测试 。 
public static void main(String[] args) 1 
ApplicationContext bf = new 
ClassPathXmlApplicationContext("aspectTest.xml"); 
IITestBean bean=(IITestBean) bf.getBean( test"); 
bean.testBeanM(); 


j 

测试 结果 与 动态 AOP 并 无 差别 ， 打 印 出 结果 : 
beforeTest 

test 


afterTest 
7.5 OP 理 


AOP 的 静态 代理 主要 是 在 虚拟 机 启动 时 通过 改变 目标 对 象 字 节 码 
的 方式 来 完成 对 目标 对 象 的 增强 ， 它 与 动态 代理 相 比 具 有 更 高 的 效 

率 ， 因 为 在 动态 代理 调用 的 过 程 中 ， 还 需要 一 个 动态 创建 代理 类 并 代 
理 目标 对 象 的 步骤 ， 而 静态 代理 则 是 在 启动 时 便 完成 了 字 节 码 增强 ， 

当 系 统 再 次 调用 目标 类 时 与 调用 正常 的 类 并 无 差别 ， 所 以 在 效率 上 会 
相对 高 些 。 


7.5.1 Instrumentation 使 用 


Java 在 1.55| 入 java.lang.instrument， 你 可 以 由 此 实现 一 个 Java 
agent， 通 过 此 agent 来 修改 类 的 字 节 码 即 改变 一 个 类 。 本 节 会 通过 
Java Instrument 实 现 一 个 简单 的 profiler。 当 然 instrument 并 不 限于 
profiler，instrument 它 可 以 做 很 多 事情 ， 它 类 似 一 种 更 低级 、 更 松 耦 合 
的 AOP， 可 以 从 底层 来 改变 一 个 类 的 行为 。 你 可 以 由 此 产生 无 限 的 遐 
想 。 授 下 来 要 做 的 事情 ， 就 是 计算 一 个 方法 所 花 的 时 间 ， 通 常 我 们 会 
在 代码 中 按 以 下 方式 编写 。 

在 方法 开头 加 入 long stime = System.nanoTime(); 在 方法 结尾 通过 
System.nanoTime()-stime 得 出 方法 所 花 时 间 。 你 不 得 不 在 想 监控 的 每 个 
方法 中 写 入 重复 的 代码 ， 好 一 点 的 情况 ， 你 可 以 用 AOP 来 干 这 事 ， 但 
总 是 感觉 有 点 别扭 ， 这 种 profiler 的 代码 还 是 要 打包 在 你 的 项 目 中 ， 
Java Instrument 使 得 这 一 切 更 干净 。 


(1) 写 ClassFileTransformer 类 。 


package org.toy; 
import java.lang.instrument.ClassFileTransformer; 
import java.lang.instrument.IllegalClassFormatException; 
import java.security.ProtectionDomain; 
import javassist. CannotCompileException; 
import javassist. ClassPool; 
import javassist. CtBehavior; 
import javassist.CtClass; 
import javassist. NotFoundException; 
import javassist.expr.ExprEditor; 
import javassist.expr. MethodCall; 
public class PerfMonXformer implements ClassFileTransformer 1 
public byte[] transform(ClassLoader loader, String className, 
Class<?> classBeingRedefined, ProtectionDomain protectionDomain, 
byte[] classfileBuffer) throws IllegalClassFormatException { 
byte[] transformed - null; 
System.out.printIn(" Transforming " + className); 
ClassPool pool = ClassPool.getDefault(); 
CtClass cl = null; 


try { 
cl = pool.makeClass(new java.io.ByteArrayInputStream( 
classfileBuffer)); 


if (cl.isInterface() == false) { 
CtBehavior[] methods = cl.getDeclaredBehaviors(); 
for (int i = 0; i < methods.length; i++) { 


if (methods[i].isEmpty() == false) 1 


/修改 method 字 节 码 
doMethod(methods[i |); 


j 
transformed - cl.toBytecode(); 
j 
} catch (Exception e) { 
System.err.println(" Could not instrument " + className 
+", exception : " + e.getMessage()); 
} finally { 
if (cl != null) { 
cl.detach(); 


j 
return transformed; 
j 
private void doMethod(CtBehavior method) throws 
NotFoundException, 
CannotCompileException 1 
method.insertBefore("long stime = System.nanoTime();"); 
method.insertA fter("System.out.println(/"leave 
"+method.getName()+" and 


time:/"+(System.nanoTime()-stime));"); 


} 
(2) 编写 agent 类 。 
package org.toy; 


import java.lang.instrument.Instrumentation; 
import java.lang.instrument.ClassFileTransformer; 
public class PerfMonA gent { 
static private Instrumentation inst = null; 
/ 米 米 
* This method is called before the application's main-method is 
called, 
* when this agent is specified to the Java VM. 


米 米 / 


public static void premain(String agentArgs, Instrumentation inst) 


System.out.printIn("PerfMonAgent.premain() was called."); 

// Initialize the static variables we use to track information. 

inst - inst; 

// Set up the class-file transformer. 

ClassFileTransformer trans = new PerfMonXformer(); 

System.out.printlIn(" Adding a PerfMonXformer instance to the 
JVM."); 


inst.addTransformer(trans); 


} 

上 面 两 个 类 就 是 agent 的 核心 了 ，JVM 启 动 时 在 应 用 加 载 前 会 调用 
PerfMonAgent.premain， 然 后 PerfMonAgent.premain 中 实例 化 了 一 个 
定制 的 ClassFileTransforme， 即 PerftMonXformer 并 通过 
inst.addTransformer(trans) 把 PerftMonXformer 的 实例 加 入 Instrumentation 
实例 (由 JVM 传 入 ) ， 这 就 使 得 应 用 中 的 类 加 载 时 ， 
PerftMonXformertransform 都 会 被 调用 ， 你 在 此 方法 中 可 以 改变 加 载 的 


类 。 真 的 有 点 神奇 ， 为 了 改变 类 的 字 节 码 ， 我 使 用 了 JBoss 的 
Javassist， 虽 然 你 不 一 定 要 这 么 用 ， 但 JBoss 的 Javassist 真 的 很 强大 ， 能 
让 你 很 容易 地 改变 类 的 字 节 码 。 在 上 面 的 方法 中 我 通过 改变 类 的 字 节 
码 ， 在 每 个 类 的 方法 入 口中 加 入 了 long stime = System.nanoTime(), 在 
方法 的 出 口 加 入 了 : 
System.out.printIn("methodClassName.methodName:"+ 
(System.nanoTime()-stime)); 
(3) 打包 agente 
对 于 agent 的 打包 ， 有 点 讲究 。 
JAR 的 META-INF/MANIFEST.MF 加 入 Premain-Class: xx, xx{E k 
语 境 中 就 是 我 们 的 agent 类 ， 即 org.toy.PerfMonAgento 
如 果 你 的 agent 类 引入 别 的 包 ， 需 使 用 Boot-Class-Path: xx，xx 在 此 
语 境 中 就 是 上 面 提 到 的 JBoss javassit, 
Bh/home/pwlazy/.m2/repository/javassist/javassist/3.8.0 .GA/ javassist- 
3.8.0.GA. jaro 
下 面 附 上 Maven 的 POM。 
[xhtml |view plaincopyprint? 
<project xmIns="http://maven.apache.org/POM/4.0.0" 
xmlns:xsi="http://www.w3.org/2001/ 
XMLSchema-instance" 
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
http://maven.apache.org/maven- 
v4_0_0.xsd"> 
<modelVersion>4.0.0</model Version> 
<groupld>org.toy</groupId> 
<artifactId>toy-inst</artifactId> 


<packaging>jar</packaging> 


<version>1.0-SNAPSHOT</version> 
<name>toy-inst</name> 
<url>http://maven.apache.org</url> 
<dependencies> 
<dependency> 
<groupId>javassist</groupId> 
<artifactId>javassist</artifactId> 
<version>3.8.0.GA</version> 
</dependency> 
<dependency> 
<groupId>junit</groupId> 
<artifactId>junit</artifactId> 
<version>3.8.1</version> 
<scope>test</scope> 
</dependency> 
</dependencies> 
<build> 
<plugins> 
<plugin> 
<groupId>org.apache.maven.plugins</groupId> 
<artifactiId>maven-jar-plugin</artifactId> 
<version>2.2</version> 
<configuration> 
<archive> 
<manifestEntries> 
<Premain-Class>org.toy. PerfMonA gent</Premain- 


Class> 


<Boot-Class- 
Path>/home/pwlazy/.m2/repository/javassist/javassist/3.8.0.GA/ 
javassist-3.8.0.GA.jar</Boot-Class-Path> 
</manifestEntries> 
</archive> 
</configuration> 
</plugin> 
<plugin> 
<artifactiId>maven-compiler-plugin «/artifactId > 
<configuration> 
<source> 1.6 </source > 
<target> 1.6 </target> 
</configuration> 
</plugin> 
</plugins> 
</build> 
</project> 
(4) 打包 应 用 。 
package org.toy; 
public class App 1 
public static void main(String[] args) 1 
new App().test(); 
i 
public void test() { 
System.out.printIn("Hello World!!"); 


Java 选 项 中 有 -javaagent:xxX， 其 中 xx 就 是 你 的 agent JAR，Java 通 过 
此 选项 加 载 agent， 由 agent 来 监控 classpath 下 的 应 用 。 

最 后 的 执行 结果 : 

PerfMonAgent.premain() was called. 

Adding a PerfMonXformer instance to the JVM. 

Transforming org/toy/App 

Hello World!! 

java.io.PrintStream.println:314216 

org.toy.App.test:540082 

Transforming java/lang/Shutdown 

Transforming java/lang/Shutdown$Lock 

java.lang.Shutdown.runHooks:29124 

java.lang.Shutdown.sequence: 132768 

由 执行 结果 可 以 看 出 ， 执 行 顺序 以 及 通过 改变 org.toy.App 的 字 节 
码 加 入 监控 代码 确实 生效 了 。 你 也 可 以 发 现 ， 通 过 Instrment 实 现 agent 
使 得 监控 代码 和 应 用 代码 完全 隔离 了 。 

通过 之 前 的 两 个 小 示例 我 们 似乎 已 经 有 所 体会 ， 在 Spring 中 的 静 
S AOP 直接 使 用 了 AspectJ 提 供 的 方法 ， 而 AspectJ 又 是 在 Instrument 基 
础 上 进行 的 封闭。 就 以 上 面 的 例子 来 看 ， 至 少 在 AspectJ 中 会 有 如 下 功 
能 。 

(1) 读 取 META-INF/aop.xml。 
(2) 将 aop.xml 中 定义 的 增强 器 通过 自 定义 的 ClassFileTransformer 

织 入 对 应 的 类 中 。 

当然 这 都 是 AspectJ 所 做 的 事情 ， 并 不 在 我 们 讨论 的 范畴 ，Spring 
是 直接 使 用 AspectJ]， 也 就 是 将 动态 代理 的 任务 直接 委托 给 了 Aspect]J， 
ABA, Spring 怎么 散 入 AspectJ 的 呢 ? 同 样 我 们 还 是 从 配置 文件 入 手 。 


7.5.2 X 标 


在 Spring 中 如 果 需 要 使 用 AspectJ 的 功能 ， 首 先 要 做 的 第 一 步 就 是 
在 配置 文件 中 加 入 配置 : <context:load-time-weaver>。 我 们 根据 之 前 
介绍 的 自 定义 命名 空间 的 知识 便 可 以 推断 ， 引 用 AspectJ 的 入 口 便 是 这 
里 ， 可 以 通过 查找 load-time-weaver 来 找到 对 应 的 自 定 义 命 名 处 理 类 
通过 Eclipse 提供 的 字符 串 搜索 功能 ， 我 们 找到 了 
ContextNamespaceHandler， 在 其 中 有 这 样 一 段 函 数 。 
public void init() 1 

registerBeanDefinitionParser("property-placeholder", new 
PropertyPlaceholder 

BeanDefinitionParser()); 

registerBeanDefinitionParser("property-override", new 
PropertyOverrideBean 

DefinitionParser()); 

registerBeanDefinitionParser("annotation-config", new 
AnnotationConfigBean 

DefinitionParser()); 

registerBeanDefinitionParser("component-scan", new 
ComponentScanBeanDefinition 

Parser()); 

registerBeanDefinitionParser("load-time-weaver", new 
LoadTimeWeaverBeanDefinition 

Parser()); 

registerBeanDefinitionParser("Spring-configured", new 
SpringConfiguredBeanDefinition 

Parser()); 


registerBeanDefinitionParser("mbean-export", new 
MBeanExportBeanDefinitionParser()); 
registerBeanDefinitionParser("mbean-server", new 
MBeanServerBeanDefinitionParser()); 
j 
继续 跟 进 LoadTimeWeaverBeanDefinitionParser， 作 为 
BeanDefinitionParser 接 口 的 实现 类 ， 他 的 核心 逻辑 是 从 parse 了 因数 开始 
的 ， 而 经 过 父 类 的 封装 ，LoadTimeWeaverBeanDefinitionParser 类 的 核 
心 实 现 被 转移 到 了 doParse 了 为 数 中 ， 如 下 : 
protected void doParse(Element element, ParserContext parserContext, 
BeanDefinition 
Builder builder) 1 
builder.setRole(BeanDefinition. ROLE INFRASTRUCTURE); 
if 
(isAspect)WeavingEnabled(element.getAttribute(ASPECTJ WEAVING A 
TTRIBUTE), 
parserContext)) 1 
RootBeanDefinition weavingEnablerDef = new 
RootBeanDefinition(); 
// ASPECTJ WEAVING ENABLER, CLASS NAME = 
// 


"org.Springframework.context.weaving.AspectJWeavingEnabler"; 


weavingEnablerDef.setBeanClassName(ASPECTJ_WEAVING_ENABLE 
R_CLASS_NAME); 


parserContext.getReaderContext().registerWithGeneratedName(weavingEn 


ablerDef); 
if 
(isBeanConfigurerAspectEnabled(parserContext.getReaderContext().getBe 


an 
ClassLoader())) 1 
new SpringConfiguredBeanDefinitionParser().parse(element, 
parserContext); 


} 


} 

其 实 之 前 在 分 析 动 态 AOP 也 就 是 在 分 析 配 置 <aop:aspectj-autoproxy 
谊 中 已 经 提 到 了 自 定义 配置 的 解析 流程 ， 对 于 <aop:aspectj-autoproxy/> 
的 解析 无 非 是 以 标签 作为 标志 ， 进 而 进行 相关 处 理 类 的 注册 ， 那 么 对 
于 自 定义 标签 <context:load-time-weaver /> 其 实 是 起 到 了 同样 的 作用 。 

上 面 汶 数 的 核心 作用 其 实 就 是 注册 一 个 对 于 ApectJ 处 理 的 类 
org.Springframework.context. weaving.AspectJWeavingEnabler, TAYE 
册 流 程 总 结 起 来 如 下 。 

(1) 是 否 开启 AspectJ。 

之 前 虽然 反复 提 到 了 在 配置 文件 中 加 入 了 <context:load-time- 
weaver/> 便 相当 于 加 入 了 AspectJ 开 关 。 但 是 ， 并 不 是 配置 了 这 个 标签 
就 意味 着 开启 了 AspectJ 功 能 ， 这 个 标签 中 还 有 一 个 属性 aspectj- 
weaving， 这 个 属性 有 3 个 备 选 值 ，on、off 和 autodetect， 默 认为 
autodetect， 也 就 是 说 ， 如 果 我 们 只 是 使 用 了 <context:load-time- 
weaver/>， 那 么 Spring 会 帮助 我 们 检测 是 否 可 以 使 用 AspecU 功 能 ， 而 
检测 的 依据 便 是 文件 META-INF/aop.xml 是 否 存在 ， 看 看 在 Spring 中 的 
实现 方式 。 


protected boolean isAspectJWeavingEnabled(String value, 
ParserContext parserContext) 1 
if ("on".equals(value)) 1 
return true; 
j 
else if ("off".equals(value)) 1 
return false; 
j 
else { 
/自动 检测 
ClassLoader cl = 
parserContext.getReaderContext().getResourceLoader(). 
getClassLoader(); 
return 
(cl.getResource(AspectJWeavingEnabler.ASPECTJ AOP XML RESOUR 
CE) != null); 
} 
} 

(2) 将 
org.Springframework.context.weaving.AspectJWeavingEnabler 封装 在 
BeanDefinition 中 注册 。 

当 通 过 AspectJ 功 能 验证 后 便 可 以 进行 AspectJWeavingEnabler 的 注 
册 了 ， 注 册 的 方式 很 简单 ， 无 非 是 将 类 路 径 注 册 在 新 初始 化 的 
RootBeanDefinition 中 ， 在 RootBeanDefinition 的 获取 时 会 转换 成 对 应 的 
classo 

尽管 在 init 方法 中 注册 了 AspectJWeavingEnabler， 但 是 对 于 标签 
本 身 Spring 也 会 以 bean 的 形式 保存 ， 也 就 是 当 Spring 解 析 到 


<context:load-time-weaver > 标签 的 时 候 也 会 产生 一 个 bean， 而 这 个 bean 
中 的 信息 是 什么 呢 ? 
T£LoadTimeWeaverBeanDefinitionParserZ$ fA 3 FF AY AEN: 
@Override 
protected String getBeanClassName(Element element) { 
if (element.hasAttributeeWEAVER_CLASS_ATTRIBUTE)) { 
return element.getAttribute(WEAVER CLASS ATTRIBUTE); 


} 
return DEFAULT_LOAD_TIME_WEAVER_CLASS_NAME; 


@Override 
protected String resolveId(Element element, AbstractBeanDefinition 
definition, 
ParserContext parserContext) 1 
return 
ConfigurableApplicationContext.,L.OAD TIME WEAVER BEAN NAME 
} 
其 中 ， 可 以 看 到 : 
WEAVER CLASS ATTRIBUTE="weaver-class" 
DEFAULT LOAD TIME WEAVER_CLASS NAME = 
"org.Springframework.context.weaving.DefaultContextLoadTimeWea 
ver"; 
ConfigurableApplicationContext..,.OAD TIME WEAVER  BEAN N 
AME=”loadTimeWeaver” 
单 任 以 上 的 信息 我 们 至 少 可 以 推断 ， 当 Spring 在 读 取 到 自 定 义 标 


签 <context:load-time-weaver/ > 后 会 产生 一 个 bean， 而 这 个 bean 的 id 为 


loadTimeWeaver，class 为 org.Springframework.context.weaving. 
DefaultContextLoadTimeWeaver， 也 就 是 完成 了 
DefaultContextLoadTimeWeaver 类 的 注册 。 
完成 了 以 上 的 注册 功能 后 ， 并 不 意味 这 在 Spring 中 就 可 以 使 用 
AspectJ 了 ， 因 为 我 们 还 有 一 个 很 重要 的 步骤 忽略 了 ， 就 是 
LoadTimeWeaverAwareProcessor 的 注册 。 在 AbstractApplicationContext 
中 的 prepareBeanFactory 国 数 中 有 这 样 一 段 代码 : 
// 增 加 对 AspectJ 的 支持 
if 
(beanFactory.containsBean(LOAD TIME WEAVER BEAN NAME)) 1 
(beanFactory)); 
beanFactory.addBeanPostProcessor(new 
LoadTimeWeaverAwareProcessor 
// Set a temporary ClassLoader for type matching. 
beanFactory.setTempClassLoader(new 
ContextTypeMatchClassLoader (beanFactory. 
getBeanClassLoader())); 
l 
在 AbstractApplicationContext 中 的 prepareBeanFactory HA ze TE S 
器 初始 化 时 候 调 用 的 ， 也 就 是 说 只 有 注册 了 
LoadTimeWeaverAwareProcessor 才 会 激活 整个 AspectJ 的 功能 。 


7.5.3 织 入 


当 我 们 完成 了 所 有 的 Aspect 的 准备 工作 后 便 可 以 进行 织 入 分 析 
了 ， 首 先 还 是 从 LoadTimeWeaverAwareProcessor 开 始 。 

LoadTimeWeaverAwareProcessor 实 现 BeanPostProcessor 方 法 ， 那 么 
对 于 BeanPostProcessor 接 口 来 讲 ，postProcessBeforelInitialization 与 


postProcessAfterInitialization 有 着 其 特殊 意义 ， 也 就 是 说 在 所 有 bean 的 
初始 化 之 前 与 之 后 都 会 分 别 调用 对 应 的 方法 ， 那 么 在 
LoadTimeWeaverAwareProcessorFHBSpostProcessBeforelnitializationEK| 2X 
中 完成 了 什么 样 的 逻辑 呢 ? 
public Object postProcessBeforeInitialization(Object bean, String 
beanName) throws 
BeansException 1 
if (bean instanceof Load TimeWeaverAware) { 
LoadTimeWeaver ltw = this.loadTimeWeaver; 
if (tw == null) 1 
Assert.state(this.beanFactory !- null, 
"BeanFactory required if no LoadTimeWeaver explicitly 
specified"); 
ltw = this.beanFactory.getBean( 


ConfigurableApplicationContext.LOAD_TIME_WEAVER_BEAN NAME 
LoadTimeWeaver.class); 
} 
((LoadTimeWeaverAware) bean).setLoadTimeWeaver(Itw); 
} 
return bean; 
} 
我 们 综合 之 前 讲解 的 所 有 信息 ， 将 所 有 相关 信息 串联 起 来 一 起 分 
析 这 个 函数 。 
在 LoadTimeWeaverAwareProcessor 中 的 
postProcessBeforelInitialization 包 | 数 中 ， 因 为 最 开始 的 if 判 断 注定 这 个 后 


处 理 器 只 对 LoadTimeWeaverAware 类 型 的 bean 起 作用 ， 而 纵 观 所 有 的 
bean， 实 现 LoadTimeWeaver 接 口 的 类 只 有 AspectJWeavingEnablero 

当 在 Spring 中 调用 AspectJWeavingEnabler 时 ，this.loadTimeWeaver 
尚未 被 初始 化 ， 那 么 ， 会 直接 调用 beanFactory.getBean 方 法 获取 对 应 的 
DefaultContextLoadTimeWeaver 类 型 的 bean， 并 将 其 设置 为 
AspectJWeavingEnabler 类 型 bean 的 loadTimeWeaver 属 性 中 。 当 然 
AspectJWeavingEnabler 同 样 实现 了 BeanClassLoaderAware 以 及 Ordered 
接口 ， 实 现 BeanClassLoaderAware 接 口 保证 了 在 bean 初 始 化 的 时 候 调 用 
AbstractAutowireCapableBeanFactory 的 invokeAwareMethods 的 时 候 将 
beanClassLoader 赋 值 给 当前 类 。 而 实现 Ordered 接 口 则 保证 在 实例 化 
bean 时 当前 bean 会 被 最 先 初 始 化 。 

而 DefaultContextLoadTimeWeaver 类 又 同时 实现 了 
LoadTimeWeaver、BeanClassLoaderAware 以 及 DisposableBean。 其 中 
DisposableBean 接 口 保证 在 bean 销 毁 时 会 调用 destroy 方 法 进行 bean 的 清 
理 ， 而 BeanClassLoaderAware 接口 则 保证 在 bean 的 初始 化 调用 
AbstractAutowireCapable BeanFactory 的 invokeAwareMethods 时 调用 
setBeanClassLoader 方 法 。 

public void setBeanClassLoader(ClassLoader classLoader) { 

LoadTimeWeaver serverSpecificLoadTimeWeaver = 
createServerSpecificLoadTimeWeaver 
(classLoader); 
if (serverSpecificLoadTimeWeaver != null) { 
if (logger.isInfoEnabled()) { 
logger.info("Determined server-specific load-time weaver: " + 
serverSpecificLoadTimeWeaver.getClass().getName()); 
j 


this.loadTimeWeaver - serverSpecificLoadTimeWeaver; 


}else if 
(InstrumentationLoadTimeWeaver.isInstrumentationAvailable()) { 
/检查 当 前 虚拟 机 中 的 Instrumentation 实 例 是 否 可 用 
logger.info("Found Spring's JVM agent for instrumentation"); 
this.loadTimeWeaver = new 
InstrumentationLoadTimeWeaver(classLoader); 
jelse { 
try 1 
this.loadTimeWeaver = new 
ReflectiveLoadTimeWeaver(classLoader); 
logger.info("Using a reflective load-time weaver for class 
loader: " + 
this.loadTimeWeaver.getInstrumentableClassLoader(). 
getClass().getName()); 
} 
catch (IllegalStateException ex) { 
throw new IllegalStateException(ex.getMessage() + " Specify 


a custom 
LoadTimeWeaver or start your " + 
"Java virtual machine with Spring's agent: -javaagent:org. 
Springframework.instrument.jar"); 
} 
} 
} 


上 面 的 函数 中 有 一 句 很 容易 被 忽略 但 是 很 关键 的 代码 : 
this.loadTimeWeaver = new 


InstrumentationLoadTimeWeaver(classLoader); 


这 句 代 码 不 仅仅 是 实例 化 了 一 个 InstrumentationLoadTimeWeaver 类 
型 的 实例 ， 而 且 在 实例 化 过 程 中 还 做 了 一 些 额外 的 操作 。 

在 实例 化 的 过 程 中 会 对 当前 的 this.instrumentation 属 性 进行 初始 
化 ， 而 初始 化 的 代码 如 下 : this.instrumentation = getInstrumentation(), 
也 就 是 说 在 InstrumentationLoadTimeWeaver 实 例 化 后 其 属性 
Instrumentation 已 经 被 初始 化 为 代表 着 当前 虚拟 机 的 实例 了 。 综 合 我 们 
讲 过 的 例子 ， 对 于 注册 转换 器 ， 如 addTransformer 遂 数 等 ， 便 可 以 直接 
使 用 此 属性 进行 操作 了 。 

也 就 是 经 过 以 上 程序 的 处 理 后 ， 在 Spring 中 的 bean 之 间 的 天 系 如 
Us 

AspectJWeavingEnabler 类 型 的 bean 中 的 loadTimeWeaver 属性 被 
初始 化 为 Default ContextLoadTimeWweaver 类 型 的 bean ; 

DefaultContextLoadTimeWeaver 类 型 的 bean 中 的 loadTimeWeaver 
属性 被 初始 化 为 InstrumentationLoadTimeWeavero 

为 AspectJWeavingEnabler 类 同样 实现 了 
BeanFactoryPostProcessor， 所 以 当 所 有 bean 解 析 结 束 后 会 调用 其 
postProcessBeanFactory 方 法 。 

public void 
postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) 
throws 

BeansException 1 

enableAspectJWeaving(this.load TimeWeaver, 

this.beanClassLoader); 

j 

public static void enableAspectJWeaving(LoadTimeWeaver 
weaverToUse, ClassLoader 

beanClassLoader) { 


if (weaverToUse == null) { 
// 此 时 已 经 被 初始 化 为 DefaultContextLoadTimeWeaver 


if (InstrumentationLoadTimeWeaver.isInstrumentationAvailable()) 


weaverToUse - new 
InstrumentationLoadTimeWeaver(beanClassLoader); 
j 
else { 
throw new IllegalStateException("No LoadTimeWeaver 
available"); 
i 
j 
// 使 用 DefaultContextLoadTimeWeaver 类 型 的 bean 中 的 
loadTimeWeaver 属 性 注册 转换 器 
weaverToUse.addTransformer(new 
AspectJClassBypassingClassFileTransformer( 
new ClassPreProcessorA gentAdapter())); 
} 
private static class AspectJClassBypassingClassFileTransformer 
implements Class 
FileTransformer { 
private final ClassFileTransformer delegate; 
public 
AspectJClassBypassingClassFileTransformer(ClassFileTransformer 
delegate) { 
this.delegate = delegate; 


public byte[] transform(ClassLoader loader, String className, Class«? 
> classBeingRedefined, 
ProtectionDomain protectionDomain, byte[] classfileBuffer) throws 
IllegalClassFormatException 1 
if (className.startsWith("org.aspectj") || className.startsWith 
("org/aspectj")) 1 
return classfileBuffer; 
j 
/委托 给 AspectJ 代 理 继续 处 理 
return this.delegate.transform(loader, className, 
classBeingRedefined, 
protectionDomain, classfileBuffer); 
j 
j 
AspectJClassBypassingClassFileTransformerfi f/F FH1X 4X 5& i 
AspectJ 以 org.aspectj 开 头 的 或 者 org/aspectj 开 头 的 类 不 进行 处 理 。 


JDBC 


JDBC (Java Data Base Connectivity，Java 数 据 库 连 接 ) 是 一 种 用 
于 执行 SQL 语句 的 Java API， 可 以 为 多 种 关系 数据 库 提 供 统 一 访问 ， 
它 由 一 组 用 Java 语 言 编写 的 类 和 接口 组 成 。JDBC 为 数据 库 开 发 人 员 提 
供 了 一 个 标准 的 API， 据 此 可 以 构建 更 高 级 的 工具 和 接口 ， 使 数据 库 
开发 人 员 能 够 用 纯 Java API 编 写 数据 库 应 用 程序 ， 并 且 可 跨 平 台 运 
行 ， 并 且 不 受 数 据 库 供应 商 的 限制 。 
JDBC 连 接 数据 库 的 流程 及 其 原理 如 下 。 
(1) 在 开发 环境 中 加 载 指定 数据 库 的 驱动 程序 。 接 下 来 的 实验 
中 ， 使 用 的 数据 库 是 MySQL， 所 以 需要 去 下 载 MySQL 支持 JDBC 的 
驱动 程序 (最 新 的 版 本 是 mysql-connector-java-5.1.18-bin.jar) ， 将 下 
载 得 到 的 驱动 程序 加 载 进 开发 环境 中 (开发 环境 是 MyEclipse， 具 体 
示例 时 会 讲解 如 何 加 载 ) o 
(2) 在 Java 程 序 中 加 载 驱 动 程序 。 在 Java 程 序 中 ， 可 以 通过 
“Class.forName(" 指 定数 据 库 的 驱动 程序 ")” 的 方式 来 加 载 添加 到 开发 环 
境 中 的 驱动 程序 ， 例 如 加 载 MySQL 的 数据 驱动 程序 的 代码 为 
Class.forName("com.mysql.jdbc.Driver"). 
(3) 创建 数据 连接 对 象 。 通 过 DriverManager 类 创建 数据 库 连 
接 对 象 Connection。DriverManager 类 作用 于 Java 程 序 和 JDBC 驱 动 程序 
之 间 ， 用 于 检查 所 加 载 的 驱动 程序 是 否 可 以 建立 连接 ， 然 后 通过 它 的 
getConnection 方 法 根据 数据 库 的 URL、 有 用户 名 和 密码 ， 创 建 一 个 JDBC 
Connection 对 象 ， 例 如 : Connection connection = 
DriverManager.geiConnection(" 连 接 数据 库 的 URL", "用 户 名 ", "密码 ”)。 
其 中 ，URL= 协 议 名 +IP 地 址 (域名) + 端口 + 数据 库 名 称 ， 用 户 名 和 密 
码 是 指 登录 数据 库 时 所 使 用 的 用 户 名 和 密码 。 具 体 示例 创建 MySQL 的 
数据 库 连 接 代码 如 下 : 
Connection connectMySQL = 


DriverManager.geiConnection(“jdbc:mysql://localhost:3306/ 


myuser","root" ,"root" ); 

(4) 创建 Statement 对 象 。Statement 类 的 主要 是 用 于 执行 静态 SQL 
语句 并 返回 它 所 生成 结果 的 对 象 。 通 过 Connection 对 象 的 
createStatement() 方 法 可 以 创建 一 个 Statement 对 象 。 例 如 : Statement 
statament = connection.createStatement()。 具 体 示 例 创 建 Statement 对 和 象 
代码 如 下 : 

Statement statamentMySQL =connectMySQL.createStatement(); 

(5) 调用 Statement 对 象 的 相关 方法 执行 相对 应 的 SQL 语句 。 通 过 
execuUpdate() 方 法 来 对 数据 更 新 ， 包 括 插 入 和 删除 等 操作 ， 例 如 向 
staff 表 中 插入 一 条 数据 的 代码 : 

statement.excuteUpdate( "INSERT INTO staff(name, age, sex,address, 
depart, 

worklen,wage)" +" VALUES (‘Tom1', 321, 'M', 
'china','Personnel',3,3000' ) ") ; 

通过 调用 Statement 对 象 的 executeQuery() 方 法 进行 数据 的 查询 ， 而 
查询 结果 会 得 到 ResulSet 对 象 ，ResulSet 表示 执行 查询 数据 库 后 返回 的 
数据 的 集合 ，ResulSet 对 象 具 有 可 以 指向 当前 数据 行 的 指针 。 通 过 该 
WRAY next() 方 法 ， 使 得 指针 指向 下 一 行 ， 然 后 将 数据 以 列 号 或 者 字 
段 名 取出 。 如 果 当 next() 方 法 返回 null， 则 表示 下 一 行 中 没有 数据 存 
在 。 使 用 示例 代码 如 下 : 

ResultSet resultSel = statement.executeQuery( "select * from staff" ); 

(6) 关闭 数据 库 连 接 。 使 用 完 数据 库 或 者 不 需要 访问 数据 库 时 ， 
通过 Connection 的 close() 方 法 及 时 关闭 数据 连接 。 
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co 


Spring 中 的 JDBC 连 接 与 直接 使 用 DBC 去 连接 还 是 有 所 差别 的 ， 
Spring 对 JDBC 做 了 大 量 封装 ， 消 除了 元 余 代 码 ， 使 得 开发 量 大 大 减 
小 。 下 面 通过 一 个 小 例子 让 大 家 简单 认识 Spring 中 的 JDBC 操 作 。 

(1) 创建 数据 表 结构 。 
CREATE TABLE user ( 
id int(11) NOT NULL auto_increment, 
'name' varchar(255) default NULL, 
'age' int(11) default NULL, 
'sex' varchar(255) default NULL, 
PRIMARY KEY (‘id’) 
) ENGINE-InnoDB DEFAULT CHARSET=utf8; 
(2) 创建 对 应 数据 表 的 PO。 
public class User { 
private int id; 
private String name; 
private int age; 
private String sex; 
/省 略 setget 方 法 
j 
(3) 创建 表 与 实体 间 的 映射 。 
public class UserRowMapper implements RowMapper 1 
@Override 
public Object mapRow(ResultSet set, int index) throws 
SQLException { 
User person = new User(set.getInt("id"), set.getString("name"), 
set 


.getInt(" age"), set.getString("sex")); 


return person; 


j 
(4) 创建 数据 操作 接口 。 
public interface UserService { 
public void save(User user); 
public List<User> getUsers(); 
} 
(5) 创建 数据 操作 接口 实现 类 。 
public class UserServiceImpl implements UserService { 
private JdbcTemplate jdbcTemplate; 
/ 设置 数据 源 
public void setDataSource(DataSource dataSource) { 
this.jdbcTemplate = new JdbcTemplate(dataSource); 
j 
public void save(User user) 1 
jdbcTemplate.update( "insert into 
user(name,age,sex)values(?,?,?)", 
new Object[] { user.getName(), user.getAge(), 
user.getSex() }, new int[] { java.sql. Types. VARCHAR, 
java.sql. Types. INTEGER, java.sql.Types. VARCHAR }); 
} 
@SuppressWarnings("unchecked") 
public List<User> getUsers() { 
List<User> list = jdbcTemplate.query("select * from user", new 
UserRowMapper()); 


return list; 


} 
(6) 创建 Spring 配 置 文 件 。 
<?xml version="1.0" encoding="UTF-8"?> 
«beans xmlns-"http://www.Springframework.org/schema/beans" 


xmins:xsi-"http://www.w3.0rg/2001/XMLSchema-instance" 


xsi:schemaLocation-"http://www.Springframework.org/schema/beans 

http://www. Springframework.org/schema/beans/Spring-beans- 
2.5.xsd 

"> 

<!-- 配 置 数据 源 --> 
<bean id="dataSource" 

class-"org.apache.commons.dbcp.BasicDataSource" 

destroy-method="close"> 

<property name="driverClassName" 
value="com.mysql.jdbc.Driver" /> 

<property name="url" 

value="jdbc:mysql://localhost:3306/lexueba" /> 

<property name-"username" value="root" /> 

<property name="password" value="haojia0421xixi" /> 

<!-- 连 接 池 启 动 时 的 初始 值 --> 

«property name="initialSize" value="1" /> 

<!-- 连 接 闻 的 最 大 值 --> 

<property name="maxActive" value="300" /> 

<!-- 最 大 空 闪 值 . 当 经 过 一 个 高 峰 时 间 后 ， 连 接 池 可 以 慢 慢 将 
已 经 用 不 到 的 连接 慢 慢 释放 一 部 分 ， 一 直 减 


少 到 maxIdle 为 止 --> 
«property name-"maxldle" value="2" /> 
«1--8/ | VE (B. SAAR) T BB, EER Maw 
申请 去 一 些 连接 ， 以 免 洪峰 来 时 来 不 及 申请 --> 
<property name-"minlIdle" value="1" /> 
</bean> 
<!-- 配 置业 务 bean: PersonServiceBean --> 
<bean id="userService" class="service.UserServicelmpl"> 
<!-- 向 属性 dataSource 注 入 数据 源 --> 
«property name-"dataSource" ref="dataSource"></property> 
</bean> 
</beans> 
(7) 测试 。 
public class SpringJDBCTest { 
public static void main(String[] args) { 
ApplicationContext act = new 
ClassPathXmlApplicationContext("bean.xml"); 
UserService userService = (UserService) 
act.getBean("userService"); 
User user = new User(); 
user.setName(" 5K ="); 
user.setA ge(20); 
user.setSex(" E"); 
// 保存 一 条 记录 
userService.save(user); 
List<User> person1 = userService.getUsers(); 


System.out.printIn("++++++++ 得 到 所 有 User"); 


for (User person2 : person1) { 
System.out.printIn(person2.getId() + " " + person2.getName() 
+" " + person2.getAge() + " " + person2.getSex()); 


} 
8.2 save/update 功 能 的 实现 


我 们 以 上 面 的 例子 为 基础 开始 分 析 Spring 中 对 JDBC 的 支持 ， 首 先 
寻找 整个 功能 的 切入 点 ， 在 示例 中 我 们 可 以 看 到 所 有 的 数据 库 操 作 都 
封装 在 了 UserServiceImpl 中 ， 而 UserServiceImpl 中 的 所 有 数据 库 操作 
又 以 其 内 部 属性 jdbcTemplate 为 基础 。 这 个 jdbcTemplate 可 以 作为 源码 
分 析 的 切入 点 ， 我 们 一 起 看 看 它 是 如 何 实现 又 是 如 何 被 初始 化 的 。 

在 UserServiceImpl 中 jdbcTemplate 的 初始 化 是 从 setDataSource 
数 开始 的 ，DataSource 实 例 通 过 参数 注入 ，DataSource 的 创建 过 程 
引入 第 三 方 的 连接 池 ， 这 里 不 做 过 多 介绍 。 isoiie ER 
操作 的 基础 ， 里 面 封装 了 整个 数据 库 的 连接 信息 。 我 们 首先 以 保存 实 
体 类 为 例 进行 代码 跟踪 。 


public void save(User user) { 


jdbcTemplate.update("insert into user(name,age,sex)values(?,?,?)", 
new Object[] { user.getName(), user.getAge(), 
user.getSex() }, new int[] { java.sql. Types. VARCHAR, 
java.sql. Types. INTEGER, java.sql. Types. VARCHAR }); 

} 

对 于 保存 一 个 实体 类 来 讲 ， 在 操作 中 我 们 只 需要 提供 SQL 语句 以 


及 语句 中 对 应 的 参数 和 参数 类 型 ， 其 他 操作 便 可 以 交 由 Spring 来 完成 


了 ， 这 些 工 作 到 底 包括 什么 呢 ? 进入 jdbcTemplate 中 的 update 方 法 。 

public int update(String sql, Object[] args, int[] argTypes) throws 
DataAccessException 1 

return update(sql, newArgTypePreparedStatementSetter(args, 

arg Iypes)); 

j 

public int update(String sql, PreparedStatementSetter pss) throws 
DataAccessException 1 


return update(new SimplePreparedStatementCreator(sql), pss); 


Xt X update 方法 后 ，Spring 并 不 是 急于 进入 核心 处 理 操作 ， 而 是 
aia ， 使 用 ArgTypePreparedStatementSetter 对 参数 与 参数 类 
进行 封闭， 同时 又 使 用 Simple PreparedStatement Creator 对 SQL 语句 
ed Ro — 么 这 么 封装 ， 暂 且 留 下 悬念 。 
经 过 了 数据 封装 后 便 可 以 进入 了 核心 的 数据 处 理 代码 了 。 
protected int update(final PreparedStatementCreator psc, final 
PreparedStatementSetter pss) 
throws DataAccessException { 
logger.debug( Executing prepared SQL update"); 
return execute(psc, new PreparedStatementCallback<Integer>() 1 
public Integer doInPreparedStatement(PreparedStatement ps) 
throws 
SQLException 1 
try 1 
if (pss != null) 1 
/设置 PreparedStatement 所 需 的 全 部 参数 。 
pss.setValues(ps); 


j 
int rows = ps.executeUpdate(); 
if (logger.isDebugEnabled()) 1 
logger.debug(" SQL update affected " + rows + " rows"); 
j 


return rows; 


j 
finally { 
if (pss instanceof ParameterDisposer) 1 


((ParameterDisposer) pss).cleanupParameters(); 


y 
} 
如 果 读 者 了 解 过 其 他 操作 方法 ， 可 以 知道 execute 方法 是 最 基础 
的 操作 ， 而 其 他 操作 比如 update、 query 等 方法 则 是 传 入 不 同 的 
PreparedStatementCallback 参 数 来 执行 不 同 的 逻辑 。 


8.2.1 法 execute 


execute 作 为 数据 库 操作 的 核心 入 口 ， 将 大 多 数 数 据 库 操作 相同 的 
步骤 统一 封 狼 ， 而 将 个 性 化 的 操作 使 用 参数 PreparedStatementCallback 
进行 回调 。 

public «T» T execute(PreparedStatementCreator psc, 
PreparedStatementCallback<T> action) 

throws DataAccessException 1 


Assert.notNull(psc, "PreparedStatementCreator must not be null"); 


Assert.notNull(action, "Callback object must not be null"); 
if (logger.isDebugEnabled()) { 
String sql = getSql(psc); 
logger.debug(" Executing prepared SQL statement" + (sql != null 


?"[" sql * "]" : 
"")); 
Í 
/获取 数据 库 连 接 


Connection con = 
DataSourceUtils.getConnection(getDataSource()); 
PreparedStatement ps = null; 
try { 
Connection conToUse = con; 
if (this.nativeJdbcExtractor != null && 
this.nativeJdbcExtractor.isNativeConnectionNecessaryForNative 
PreparedStatements()) { 
conToUse = 
this.nativeJdbcExtractor.getNativeConnection(con); 
} 
ps = psc.createPreparedStatement(conToUse); 
// 应 用 用 户 设 定 的 输入 参数 
applyStatementSettings(ps); 
PreparedStatement psToUse = ps; 
if (this.nativeJdbcExtractor != null) { 
psToUse = 
this.nativeJdbcExtractor.getNativePreparedStatement(ps); 
} 


/调用 回调 函数 
T result = action.doInPreparedStatement(psToUse); 
handleWarnings(ps); 
return result; 
j 
catch (SQLException ex) 1 
/释放 数据 库 连 接 避 免 当 异常 转换 器 没有 被 初始 化 的 时 候 出 
现 潜在 的 连接 闻 死 锁 
if (psc instanceof ParameterDisposer) { 


((ParameterDisposer) psc).cleanupParameters(); 


j 
String sql = getSql(psc); 
psc - null; 


JdbcUtils.closeStatement(ps); 

ps = null; 

DataSourceUtils.releaseConnection(con, getDataSource()); 
con - null; 


throw 


getExceptionTranslator().translate(" PreparedStatementCallback", sql, ex); 
j 
finally { 
if (psc instanceof ParameterDisposer) 1 
((ParameterDisposer) psc).cleanupParameters(); 
j 
JdbcUtils.closeStatement(ps); 


DataSourceUtils.releaseConnection(con, getDataSource()); 


j 
以 上 方法 对 常用 操作 进行 了 封装 ， 包 括 如 下 几 项 内 容 。 
1. 获取 数据 库 连接 
获取 数据 库 连 接 也 并 非 直接 使 用 dataSource.getConnection() 方 法 那 
么 简单 ， 同 样 也 考虑 了 诸多 情况 。 
public static Connection doGetConnection(DataSource dataSource) 
throws SQLException 1 
Assert.notNull(dataSource, "No DataSource specified"); 
ConnectionHolder conHolder = (ConnectionHolder) 
TransactionSynchronization 
Manager.getResource(dataSource); 
if (conHolder != null && (conHolder.hasConnection() || 
conHolder.isSynchronized 
With Transaction())) 1 
conHolder.requested(); 
if (!conHolder.hasConnection()) 1 
logger.debug("Fetching resumed JDBC Connection from 
DataSource"); 
conHolder.setConnection(dataSource.getConnection()); 
j 
return conHolder.getConnection(); 
j 
logger.debug("Fetching JDBC Connection from DataSource"); 
Connection con = dataSource.getConnection(); 
// 当 前 线程 支持 同步 


if (TransactionS ynchronizationManager.isSynchronizationActive()) 


logger.debug(" Registering transaction synchronization for JDBC 
Connection"); 
/在 事务 中 使 用 同一 数据 库 连 接 
ConnectionHolder holderToUse = conHolder; 
if (holderToUse == null) 1 
holderToUse = new ConnectionHolder(con); 
j 
else { 
holderToUse.setConnection(con); 
j 
/记录 数据 库 连 接 
holderToUse.requested(); 
TransactionSynchronizationManager.registerSynchronization( 
new ConnectionSynchronization(holderToUse, dataSource)); 
holderToUse.setSynchronizedWithTransaction(true); 
if (holderToUse != conHolder) { 


TransactionSynchronizationManager.bindResource(dataSource, 
holderToUse); 
j 
i 
return con; 


} 
在 数据 库 连 接 方面 ，Spring 主 要 考虑 的 是 关于 事务 方面 的 处 理 。 


基于 事务 处 理 的 特殊 性 ， Spring 需要 保证 线程 中 的 效 据 库 操作 都 是 使 
用 同一 个 事务 连接 。 
2. 应 用 用 户 设 定 的 输入 参数 


protected void applyStatementSettings(Statement stmt) throws 
SQLException 1 
int fetchSize = getFetchSize(); 
if (fetchSize > 0) { 
stmt.setFetchSize(fetchSize); 
j 
int maxRows = getMaxRows(); 
if (maxRows > 0) { 
stmt.setMaxRows(maxRows); 
j 
DataSourceUtils.applyTimeout(stmt, getDataSource(), 
getQueryTimeout()); 
j 
setFetchSize 最 主要 是 为 了 减少 网 络 交 互 次 数 设 计 的 。 访 问 
ResultSet 时 ， 如 果 它 每 次 只 从 服务 器 上 读 取 一 行 数 据 ， 则 会 产生 大 量 
的 开销 。setFetchSize 的 意思 是 当 调 用 rs.next 时 ，ResultSet 会 一 次 性 从 
服务 器 上 取得 多 少 行 数据 回来 ， 这 样 在 下 次 rs.next 时 ， 它 可 以 直接 从 
内 存 中 获取 数据 而 不 需要 网 络 交 互 ， 提 高 了 效率 。 这 个 设置 可 能 会 被 
某 些 JDBC 驱动 忽略 ， 而 且 设置 过 大 也 会 造成 内 存 的 上 升 。 
setMaxRows 将 此 Statement 对 象 生成 的 所 有 ResultSet 对 象 可 以 包含 
的 最 大 行 数 限 制 设置 为 给 定数 。 
3. 调用 回调 函数 
处 理 一 些 通用 方法 外 的 个 性 化 处 理 ,也 就 是 
PreparedStatementCallback 类 型 的 参数 的 doInPreparedStatement 方 法 的 
回调 。 
4. 警告 处 理 


protected void handleWarnings(Statement stmt) throws SQLException 


/ 当 设 置 为 忽略 警告 时 只 IS INT EN 日 志 
if (isIgnoreWarnings()) 1 


if (logger.isDebugEnabled()) 1 
/如 果 日 志 开 局 的 情 况 下 打印 日 志 ICA 


SQLWarning warningToLog = stmt.getWarnings() 
while (warningToLog !- null) 1 


logger.debug(" SQLWarning ignored: SQL state "+ 
warningToLog. 


getSQLState() + "", error code " + 


warning ToLog.getErrorCode() + "', message [" + 
warning [oLog. 
getMessage() + "J"; 
warningToLog = warningToLog.getNextWarning() 
} 


} 
else { 


handleWarnings(stmt.getWarnings()) 
} 


这 里 用 到 了 一 个 类 SQLWarning，SQLWarning 提 供 关 于 数据 库 访问 
2a nem 这 些 和 警告 直接 链接 到 导致 报 


He Bide Ae hh 
A anA 


的 方法 所 在 的 对 
。 警告 可 以 从 Connection、Statement 和 ResultSet 对 象 中 
已 经 VICE x 


获得 。 试 图 在 
已 经 关闭 的 连接 上 获取 警告 将 导致 抛 出 异 单 。 类 似 地 ， 试 图 在 已 经 天 


闭 的 语句 上 或 已 经 关闭 的 结果 集 上 获取 和 警告 也 将 导致 抛 出 异常 。 注 
意 ， 关 闭 语句 时 还 会 关闭 它 可 能 生成 的 结果 集 。 

很 多 人 不 是 很 理解 什么 情况 下 会 产生 警告 而 不 是 异常 ， 在 这 里 给 
读者 提示 个 最 常见 的 警告 DataTruncation: DataTruncation 直 接 继 承 
SQLWarning， 由 于 某 种 原因 意外 地 截断 数据 值 时 会 以 DataTruncation 
警告 形式 报告 异常 。 

对 于 警告 的 处 理 方式 并 不 是 直接 抛 出 异常 ， 出 现 警 告 很 可 能 会 出 
现 数据 错误 ， 但 是 ， 并 不 一 定 会 影响 程序 执行 ， 所 以 用 户 可 以 自己 设 
置 处 理 警 告 的 方式 ， 如 默认 的 是 忽略 警告 ， 当 出 现 警 告 时 只 打印 警告 
日 志 ， 而 另 一 种 方式 只 直接 抛 出 异常 。 

5. 资源 释放 

数据 库 的 连接 释放 并 不 是 直接 调用 了 Connection 的 API 中 的 close 方 
法 。 考 虑 到 存在 事务 的 情况 ， 如 果 当 前 线程 存在 事务 ， 那 么 说 明 在 当 
前 线程 中 存在 共用 数据 库 连接 ， 这 种 情况 下 直接 使 用 ConnectionHolder 
中 的 released 方 法 进行 连接 数 减 一 ， 而 不 是 真正 的 释放 连接 。 

public static void releaseConnection(Connection con, DataSource 
dataSource) { 

try { 
doReleaseConnection(con, dataSource); 
} 
catch (SQLException ex) { 
logger.debug("Could not close JDBC Connection", ex); 
i 
catch (Throwable ex) { 
logger.debug(" Unexpected exception on closing JDBC 
Connection", ex); 


} 


public static void doReleaseConnection(Connection con, 
DataSource dataSource) throws 
SQLException 1 
if (con == null) 1 
return; 
j 
if (dataSource != null) 1 
/当前 线程 存在 事务 的 | 
使 用 ConnectionHolder 中 的 
released 方 法 进行 连接 数 减 一 而 不 是 真正 的 释放 连接 。 


ConnectionHolder conHolder = (ConnectionHolder) 


青 况 下 说 明 存 在 共用 效 据 库 连接 直接 


TransactionSynchronization 
Manager.getResource(dataSource); 
if (conHolder != null && connectionEquals(conHolder, con)) 1 
// It's the transactional Connection: Don't close it. 
conHolder.released(); 


return; 


} 
if (!(dataSource instanceof SmartDataSource) || ((SmartDataSource) 
dataSource). shouldClose(con)) 1 
logger.debug(" Returning JDBC Connection to DataSource"); 


con.close(); 


8.2.2 Update 


PreparedStatementCallback 作 为 一 个 接口 ， 其 中 只 有 一 个 函数 
doInPreparedStatement， 这 个 函数 是 用 于 调用 通用 方法 execute 的 时 候 无 
法 处 理 的 一 些 个 性 化 处 理 方法 ， 在 update 中 的 函数 实现 : 

public Integer doInPreparedStatement(PreparedStatement ps) throws 
SQLException 1 

try { 
if (pss != null) 1 
/设置 PreparedStatement 所 需 的 全 部 参数 。 
pss.setValues(ps); 
j 
int rows = ps.executeUpdate(); 
if (logger.isDebugEnabled()) { 
logger.debug("SQL update affected " + rows + " rows"); 
j 
return rows; 
j 
finally 1 
if (pss instanceof ParameterDisposer) 1 


((ParameterDisposer) pss).cleanupParameters(); 


} 

其 中 用 于 真正 执行 SQL 的 ps.executeUpdate 没 有 太 多 需要 讲解 的 , 
因为 我 们 平时 在 直接 使 用 JDBC 方 式 进行 调用 的 时 候 会 经 单 使 用 此 方 
法 。 但 是 ， 对 于 设置 输入 参数 的 水 数 pss.setValues (ps)， 我 们 有 必要 去 


深入 研究 一 下 。 在 没有 分 析 源 码 之 前 ， 我 们 至 少 可 以 知道 其 功能 ， 不 

妨 再 回顾 下 Spring 中 使 用 SQL 的 执行 过 程 ， 直 接 使 用 : 
jdbcTemplate.update( "insert into user(name,age,sex)values(?,?,?)", 
new Object[] { user.getName(), user.getAge(), 

user.getSex() }, new int[] { java.sql. Types. VARCHAR, 

java.sql. Types. INTEGER, java.sql. Types. VARCHAR }); 

SQL 语句 对 应 的 参数 ， 对 应 参数 的 类 型 清晰 明了 ， 这 都 归功 于 
Spring 为 我 们 做 了 封装 ， 而 真正 的 JDBC 调 用 其 实 非 常 繁琐 ， 你 需要 这 
么 做 : 

PreparedStatement updateSales = con.prepareStatement("insert into 
user(name,age, 

sex)values(?,?,?)"); 

updateSales.setString(1, user.getName()); 

updateSales.setInt(2, user.getAge()); 

updateSales.setString(3, user.getSex()); 

那么 看 看 Spring 是 如 何 做 到 封装 上 面 的 操作 呢 ? 

首先 ， 所 有 的 操作 都 是 以 pss.setValues(ps) 为 入 口 的 。 还 记得 我 们 
之 前 的 分 析 路 程 吗 ? 这 个 pss 所 代表 的 当前 类 正 是 
ArgPreparedStatementSetter。 其 中 的 setValues 如 下 : 

public void setValues(PreparedStatement ps) throws SQLException { 

int parameterPosition = 1; 
if (this.args != null) { 
/遍历 每 个 参数 以 作 类 型 匹配 及 转换 
for (int i = 0; i < this.args.length; i++) ( 
Object arg = this.args[i]; 
/如 果 是 集合 类 则 需要 进入 集合 类 内 部 递归 解析 集合 内 部 


if (arg instanceof Collection && this.argTypes[i] != 
Types.ARRAY) { 
Collection entries = (Collection) arg; 
for (Iterator it — entries.iterator(); it.hasNext();) 1 
Object entry = it.next(); 
if (entry instanceof Object[]) { 
Object[] valueArray = ((Object[])entry); 
for (int k = 0; k < valueArray.length; k++) ( 
Object argValue = valueArray[k]; 
doSetValue(ps, parameterPosition, this.argTypes[i], 
arg Value); 
parameterPosition++; 
} 
jelse { 
doSetValue(ps, parameterPosition, this.argTypes[i], 
entry); 


parameterPosition++; 


jelse { 
// 解 析 当 前 属性 
doSetValue(ps, parameterPosition, this.argTypes][i], arg); 


parameterPosition++; 


对 单个 参数 及 类 型 的 匹配 处 理 : 
protected void doSetValue(PreparedStatement ps, int 
parameterPosition, int arg Iype, Object argValue) 
throws SQLException 1 
StatementCreatorUtils.setParameterValue(ps, parameterPosition, 
argTIype, argValue); 
j 
public static void setParameterValue( 
PreparedStatement ps, int paramIndex, int sql Type, Object inValue) 
throws SQLException 1 
setParameterValueInternal(ps, paramIndex, sql Type, null, null, 
inValue); 
j 
private static void setParameterValueInternal( 
PreparedStatement ps, int paramIndex, int sql Type, String typeName, 
Integer 
scale, Object inValue) 
throws SQLException 1 
String typeNameToUse = typeName; 
int sqlTypeToUse = sql Type; 
Object inValueToUse = inValue; 
if (inValue instanceof SqlParameterValue) { 
SqlParameterValue parameterValue = (SqlParameterValue) 
inValue; 
if (logger.isDebugEnabled()) 1 
logger.debug( Overriding type info with runtime info from 


SqlParameter Value: 


column index " + paramIndex + 
", SQL type " + parameter Value.getSqlType() + 
", Type name " + parameterValue.getTypeName()); 
} 
if (parameterValue.getSqlType() != 
SqlTypeValue. TYPE. UNKNOWN) 1 
sql TypeToUse = parameterValue.getSqlType(); 
j 
if (parameterValue.getTypeName() !- null) 1 
typeNameToUse = parameterValue.get TypeName(); 
} 
inValueToUse = parameterValue.get Value(); 
} 
if (logger.isTraceEnabled()) { 
logger.trace(" Setting SQL statement parameter value: column 
index " + 
paramIndex + 
", parameter value [" + inValueToUse + 
"], value class [" + (inValueToUse != null ? inValueToUse. 
getClass().getName() : "null") + 
"], SQL type " + (sqlTypeToUse == 
SqlTypeValue.TYPE_UNKNOWN ? 
"unknown" : Integer.toString(sqlTypeToUse))); 
} 
if (inValueToUse == null) { 
setNull(ps, paramIndex, sqlTypeToUse, typeNameToUse); 


else { 
setValue(ps, paramIndex, sqlTypeToUse, typeNameToUse, scale, 
inValueToUse); 
} 
j 


8.3 query 功 能 的 实现 


在 之 前 的 章节 中 我 们 介绍 了 update 方 法 的 功能 实现 ， 那 么 在 数据 
库 操 作 中 查找 操作 也 是 使 用 率 非常 高 的 国 数 ， 同 样 我 们 也 需要 了 解 它 
的 实现 过 程 。 使 用 方法 如 下 : 

List<User> list = jdbcTemplate.query("select * from user where 
age=?" new 

Object[]{20},new int[]{java.sql. Types. INTEGER} ,new 
UserRowMapper()); 

跟踪 jdbcTemplate 中 的 query 方 法 。 

public <T> List<T> query(String sql, Object[] args, int[] argTypes, 
RowMapper<T> rowMapper) 

throws DataAccessException 1 

return query(sql, args, argTypes, new 
RowMapperResultSetExtractor<T> 
(rowMapper)); 

} 

public <T> T query(String sql, Object[] args, int[] argTypes, 
ResultSetExtractor« T^ rse) 


throws DataAccessException { 


return query(sql, newArgTypePreparedStatementSetter(args, 
argTypes), rse); 
j 
mR Zi Fh E update75 AP BB IS] ES FH T 
newArgTypePreparedStatementSettero 
public <T> T query(String sql, PreparedStatementSetter pss, 
ResultSetExtractor« T^ rse) 
throws DataAccessException { 
return query(new SimplePreparedStatementCreator(sql), pss, rse); 
j 
public <T> T query( 
PreparedStatementCreator psc, final PreparedStatementSetter pss, final 
ResultSetExtractor« T^ rse) 
throws DataAccessException { 
Assert.notNull(rse, "ResultSetExtractor must not be null"); 
logger.debug(""Executing prepared SQL query"); 
return execute(psc, new PreparedStatementCallback<T>() 1 
public T doInPreparedStatement(PreparedStatement ps) throws 
SQLException 1 
ResultSet rs - null; 
try 1 
if (pss != null) 1 
pss.setValues(ps); 
j 
rs = ps.executeQuery(); 
ResultSet rsToUse - rs; 


if (nativeJdbcExtractor != null) { 


rsToUse = nativeJdbcExtractor.getNativeResultSet(rs); 
j 
return rse.extractData(rs ToUse); 
j 
finally { 
JdbcUtils.closeResultSet(rs); 
if (pss instanceof ParameterDisposer) 1 


((ParameterDisposer) pss).cleanupParameters(); 


y 
j 
可 以 看 到 整体 套路 与 update 差 不 多 的 ， 只 不 过 在 回调 类 
PreparedStatementCallback 的 实现 中 使 用 的 是 ps.executeQuery() 执 行 查询 
操作 ， 而 且 在 返回 方法 上 也 做 了 一 些 额 外 的 处 理 。 
rse.extractData(rsToUse) 方 法 负责 将 结果 进行 封装 并 转换 至 
POJO, rse 当前 代表 的 类 为 RowMapperResultSetExtractor， 而 在 构造 
RowMapperResultSetExtractor 的 时 候 我 们 又 将 自 定义 的 rowMapper 设 置 
了 进去 。 调 用 代码 如 下 : 
public List<T> extractData(ResultSet rs) throws SQLException 1 
List<T> results = (this.rowsExpected > 0 ? new ArrayList« T^ 
(this.rowsExpected) : 
new ArrayList<T>()); 
int rowNum = 0; 
while (rs.next()) 1 


results.add(this.rowMapper.mapRow(rs, rowNum:---)); 


j 
return results; 
j 
上 面 的 代码 中 并 没有 什么 复杂 的 逻辑 ， 只 是 对 返回 结果 遍历 并 以 
此 使 用 rowMapper 进 行 转换 。 
之 前 讲 了 update 方 法 以 及 query 方 法 ， 使 用 这 两 个 图 数 示例 的 SQL 
都 是 带 有 参数 的 ， 也 就 是 带 有 “? ”的 ， 那 么 还 有 另 一 种 情况 是 不 带 有 
“?" 的 ，Spring 中 使 用 的 是 另 一 种 处 理 方式 。 例 如 : 
List<User> list = jdbcTemplate.query("select * from user", new 
UserRowMapper()); 
跟踪 进入 : 
public <T> List<T> query(String sql, RowMapper<T> rowMapper) 
throws DataAccessException { 
return query(sql, new RowMapperResultSetExtractor<T> 
(rowMapper)); 
j 
public <T> T query(final String sql, final ResultSetExtractor<T> rse) 
throws 
DataAccessException 1 
Assert.notNull(sql, "SQL must not be null"); 
Assert.notNull(rse, "ResultSetExtractor must not be null"); 
if (logger.isDebugEnabled()) { 
logger.debug(" Executing SQL query [" + sql + "]"); 
j 
class QueryStatementCallback implements StatementCallback<T>, 
SqlProvider { 
public T doInStatement(Statement stmt) throws SQLException { 


ResultSet rs = null; 
try { 
rs = stmt.executeQuery(sql); 
ResultSet rsToUse - rs; 
if (nativeJdbcExtractor != null) { 
rsToUse - nativeJdbcExtractor.getNativeResultSet(rs); 
j 


return rse.extractData(rsToUse); 
j 
finally { 
JdbcUtils.closeResultSet(rs); 


j 
public String getSql() { 


return sql; 


} 


return execute(new QueryStatementCallback()); 


j 

与 之 前 的 query 方法 最 大 的 不 同 是 少 了 参数 及 参数 类 型 的 传递 ， 
自然 也 少 了 Prepared StatementSetter 类 型 的 封装 。 既 然 少 了 
PreparedStatementSetter 类 型 的 传 入 ， 调 用 的 execute 方 法 自然 也 会 有 所 
改变 了 。 


public <T> T execute(StatementCallback<T> action) throws 


DataAccessException 1 
Assert.notNull(action, "Callback object must not be null"); 


Connection con = 
DataSourceUtils.getConnection(getDataSource()); 
Statement stmt = null; 
try { 
Connection con ToUse = con; 
if (this.nativeJdbcExtractor != null && 
this.nativeJdbcExtractor.isNativeConnectionNecessary ForNative 
Statements()) 1 
conToUse = 
this.nativeJdbcExtractor.getNativeConnection(con); 
j 
stmt = conToUse.createStatement(); 
applyStatementSettings(stmt); 
Statement stmtToUse = stmt; 
if (this.nativeJdbcExtractor != null) { 
stmtToUse = 
this.nativeJdbcExtractor.getNativeStatement(stmt); 
} 
T result = action.doInStatement(stmtToUse); 
handleWarnings(stmt); 
return result; 
} 
catch (SQLException ex) { 
// Release Connection early, to avoid potential connection pool 
deadlock 
// in the case when the exception translator hasn't been initialized 


yet. 


JdbcUtils.closeStatement(stmt); 
stmt = null; 
DataSourceUtils.releaseConnection(con, getDataSource()); 
con - null; 
throw getExceptionTranslator().translate(" StatementCallback", 
getSql(action), ex); 
j 
finally { 
JdbcUtils.closeStatement(stmt); 


DataSourceUtils.releaseConnection(con, getDataSource()); 


} 

这 个 exexute 与 之 前 的 execute 并 无 太 大 差别 ， 都 是 做 一 些 常规 的 处 
理 ， 诸 如 获取 连接 、 释 连接 等 ， 但 是 ， 有 一 个 地 方 是 不 一 样 的 ， 就 是 
statement 的 创建 。 这 里 直接 使 用 connection 创 建 ， 而 带 有 参数 的 SQL 使 
用 的 是 PreparedStatementCreator 类 来 创建 的 。 一 个 是 普通 的 
Statement， 另 一 个 是 PreparedStatement， 两 者 究竟 是 何 区 别 呢 ? 

PreparedStatement 接 口 继 承 Statement， 并 与 之 在 两 方面 有 所 不 
同 。 

PreparedStatement 实 例 包含 已 编译 的 SQL 语句 。 这 就 是 使 语句 “ 准 
备 好 ”。 包 含 于 PreparedStatement 对 象 中 的 SQL 语句 可 具有 一 个 或 多 个 
IN 参数 。IN 人 参数 的 值 在 SQL 语句 创建 时 未 被 指定 。 相 反 的 ， 该 语句 为 
每 个 IN 参数 保留 一 个 问号 ("?") 作为 占 位 符 。 每 个 问号 的 值 必须 在 该 
语句 执行 之 前 ， 通 过 适当 的 setXXX 方 法 来 提供 。 

由 于 PreparedStatement 对 象 已 预 编译 过 ， 所 以 其 执行 速度 要 快 于 
Statement 对 象 。 因 此 ， 多 次 执行 的 SQL 语句 经 单 创建 为 
PreparedStatement 对 象 ， 以 提高 效率 。 


作为 Statement 的 子 类 ，PreparedStatement 继 承 了 Statement 的 所 有 
功能 。 另 外 ， 它 还 添加 了 一 整套 方法 ， 用 于 设置 发 送 给 数据 库 以 取代 
IN 参 数 占 位 符 的 值 。 同 时 ， 三 种 方法 execute、executeQuery 和 
executeUpdate 已 被 更 改 以 使 之 不 再 需要 参数 。 这 些 方法 的 Statement 形 
式 (接受 SQL 语句 参数 的 形式 ) 不 应 该 用 于 PreparedStatement 对 象 。 


.4 queryForObject 


Spring 中 不 仅仅 为 我 们 提供 了 query 方 法 ， 还 在 此 基础 上 做 了 封 
装 ， 提 供 了 不 同类 型 的 query 方 法 ， 如 图 8-1 所 示 。 


queryfor| 
4 K9 JdbcTemplate 
© 4 queryForMap(String) : Map «String, Object» 


6 4 queryForObject(String, RowMapper«T») «T» :1 
© 4 queryForObject(String, Class«T») «T» :T 

6 4 queryForLong(String) : long 

9 4 queryForint(String) : int 

© 4 queryForList(String, Class«T») «T» :List<T> 

9 4 queryForList(String) : List« Map «String, Object» > 

9 4 queryForRowSet(String) : SalRowSet 

6 4 queryForObject(String, Object[], int[], RowMapper<T=) «T» :T 
© 4 queryForObject(String, Object[], RowMapper«T») «T» :T 

9 4 queryForObject(String, RowMapper<T=, Object...) «T» :T 

© 4 queryForObject(String, Object[], int], Class«T») «T> :T 

9 4 queryForObject(String, Object[], Class«T») «T» :T 

9 4 queryForObject(String, Class <T>, Object...) <T> :T 

© 4 queryForMap(String, Object[], int[]) : Map «String, Object» 

© 4 queryForMap(String, Object...) : Map «String, Object» 

6 4 queryForLong(String, Object[], int[]) : long 

9 4 queryForLong(String, Object...) : long 

© 4 queryForlnt(String, Object[], int[] : int 

© 4 queryForint(String, Object...) : int 

© 4 queryForList(String, Object[], int[], Class<T=) «T» : List<T= 

© 4 queryForList(String, Object[], Class <T>) «T» : List<T= 

© 4 queryForList(String, Class«T», Object...) «T» :List«T» 

© 4 queryForList(String, Object[], int[]) : List« Map «String, Objects = 
9 4 queryForList(String, Object..) : List« Map «String, Object» » 

© 4 queryForRowSet(String, Object[], int[] : SalRowSet 

9 a queryForRowSet(String, Object...) : SqlRowSet 


图 8-1 Spring 中 的 query 相 关 方 法 


我 们 以 queryForObject 为 例 ， 来 讨论 一 下 Spring 是 如 何在 返回 结 
的 基础 上 进行 封装 的 。 
public «T» T queryForObject(String sql, Class<T> requiredType) 


throws DataAccessException { 


return queryForObject(sql, 
getSingleColumnRowMapper(requiredType)); 
j 
public «T» T queryForObject(String sql, RowMapper<T> 
rowMapper) throws DataAccessException 1 
List« T^ results = query(sql, rowMapper); 


return DataAccessUtils.requiredSingleResult(results); 


j 
其 实 最 大 的 不 同 还 是 对 于 RowMapper 的 使 用 。 
SingleColumnRowMapper 类 中 的 mapRow: 
public T mapRow(ResultSet rs, int rowNum) throws SQLException { 
// 验 证 返回 结果 数 
ResultSetMetaData rsmd = rs.getMetaData(); 
int nrOfColumns = rsmd.getColumnCount(); 
if (nrOfColumns != 1) { 
throw new IncorrectResultSetColumnCountException(1, 
nrOfColumns); 
j 
/抽取 第 一 个 结果 进行 处 理 
Object result = getColumnValue(rs, 1, this.requiredType); 
if (result != null && this.requiredType != null && 
Ithis.requiredType. 
isInstance(result)) 1 
/转换 到 对 应 的 类 型 
try { 
return (T) convertValueToRequiredType(result, 
this.requiredType); 


j 
catch (IllegalArgumentException ex) 1 
throw new TypeMismatchDataA ccessException( 
"Type mismatch affecting row number " + rowNum + " and 
column 
type" + 
rsmd.getColumnTypeName(1) + ": " + ex.getMessage()); 


j 
return (T) result; 
j 
对 应 的 类 型 转换 函数 : 
protected Object convertValueToRequiredType(Object value, Class 
requiredType) 1 
if (String.class.equals(requiredType)) 1 
return value.toString(); 
j 
else if (Number.class.isAssignableFrom(requiredType)) { 
if (value instanceof Number) { 
// Convert original Number to target Number class. 
/转换 原始 Number 类 型 的 实体 到 Number 类 
return NumberUtils.convertNumberToTargetClass(((Number) 
value), 
requiredType); 
jelse 1 
/转换 string 类 型 的 值 到 Number 类 


return NumberUtils.parseNumber(value.toString(), 
requiredType); 
} 
} 
else { 
throw new IllegalArgumentException( 


"Value [" + value + "] is of type [" + value.getClass().getName() 


"] and cannot be converted to required type [" + requiredType. 
getName() + "J"; 
} 


第 9 章 ”整合 MyBatis 


MyBatis 本 是 Apache 的 一 个 开源 项 目 iBatis，2010 年 这 个 项 目 由 

Apache Software Foundation 迁 移 到 了 Google Code， 并 且 改 名 为 MyBatis 
(下 载 地 址 为 http://code.google.com/p/mybatis/) o 

MyBatis 是 支持 普通 SQL 查 询 、 存 储 过 程 和 高 级 映射 的 优秀 持久 
层 框 架 。MyBatis 消 除了 几乎 所 有 的 JDBC 代 码 和 参数 的 手工 设置 以 及 
结果 集 的 检索 。MyBatis 使 用 简单 的 XML 或 注解 用 于 配置 和 原始 映 
射 ， 将 接口 和 Java 的 POJOs (Plain Old Java Objects， 普 通 的 Java 对 象 ) 
映射 成 数据 库 中 的 记录 。 


9.1 MyBatis 独 立 使 用 


尽管 我 们 接触 更 多 的 是 MyBatis 与 Spring 的 整合 使 用 ， 但 是 
MyBatis 有 它 自己 的 独立 使 用 方法 ， 了 解 其 独立 使 用 的 方法 套路 对 分 析 
Spring 整合 MyBatis 非 常 有 帮助 ， 因 为 Spring 无 非 就 是 将 这 些 功能 进行 
封装 以 简化 我 们 的 开发 流程 。MyBatis 独 立 使 用 包括 以 下 几 步 。 

(1) 建立 PO。 

用 于 对 数据 库 中 数据 的 映射 ， 使 程序 员 更 关注 于 对 Java 类 的 使 用 
而 不 是 数据 库 的 操作 。 

public class User { 

private Integer id; 

private String name; 
private Integer age; 
/省 略 set/get 方 法 
public User(String name, Integer age) { 
super(); 
this.name = name; 
this.age = age; 
j 
public User() 1 
super(); 
} /必须 要 有 这 个 无 参 构造 方法 ， 不 然 根据 UserMapperxml 中 的 
配置 ， 在 查询 数据 库 时 ， 将 不 能 反射 构造 出 
User 实 例 
} 
(2) 建立 Mappero 
数据 库 操作 的 映射 文件 ， 也 就 是 我 们 常常 说 的 DAO， 用 于 映射 数 
据 库 的 操作 ， 可 以 通过 配置 文件 指定 方法 对 应 的 SQL 语句 或 者 直接 使 
用 Java 提 供 的 注解 方式 进行 SQL 指定 。 


public interface UserMapper { 
public void insertUser(User user); 
public User getUser(Integer id); 
j 
(3) 建立 配置 文件 。 
配置 文件 主要 用 于 配置 程序 中 可 变性 高 的 设置 ， 一 个 偏 大 的 程序 
一 定 会 存在 一 些 经 常会 变化 的 变量 ， 如 果 每 次 变化 都 需要 改变 源码 那 
会 是 非常 糟糕 的 设计 ， 所 以 ， 我 们 看 到 各 种 各 样 的 框架 或 者 应 用 的 时 
候 都 免不了 要 配置 配置 文件 ，MyBatis 中 的 配置 文件 主要 封装 在 
configuration 中 ， 配 置 文件 的 基本 结构 如 图 9-1 所 示 。 


databaseIdProvider § 


typeAliases 
= typeHandlers 


objectFactory 


图 9-1 配置 文件 结构 


configuration: 根 元 素 。 

properties: 定义 配置 外 在 化 。 

settings: 一 些 全 局 性 的 配置 。 

typeAliases: 为 一 些 类 定义 别名 。 

typeHandlers: 定义 类 型 处 理 ， 也 就 是 定义 Java 类 型 与 数据 库 中 
的 数据 类 型 之 间 的 转换 关系 。 


objectFactory: 用 于 指定 结果 集 对 象 的 实例 是 如 何 创建 的 。 
plugins: MyBatis 的 插件 ， 插 件 可 以 修改 MyBatis 内 部 的 运行 规 
则 。 
environments: 环境 。 
environment: 配置 MyBatis 的 环境 。 
transactionManager: 事务 管理 器 。 
dataSource: 数据 源 。 
mappers: 指定 映射 文件 或 映射 类 。 
读者 如 果 对 上 面 的 各 个 配置 具体 使 用 方法 感 兴 趣 ， 可 以 进一步 查 
阅 相关 资料 ， 这 里 只 举 出 最 简单 的 实例 以 方便 读者 快速 回顾 MyBatis。 
<?xml version="1.0" encoding="UTF-8"?> 
«IDOCTYPE configuration 
PUBLIC "-//mybatis.org//DTD Config 3.0//EN" 
"http://mybatis.org/dtd/mybatis-3-config.dtd"> 
<configuration> 
<settings> 
<!-- changes from the defaults for testing --> 
<setting name="cacheEnabled" value="false" /> 
«setting name="useGeneratedKeys" value="true" /> 
«setting name-"defaultExecutorType" value="REUSE" /> 
</settings> 
<typeAliases> 
<typeAlias alias="User" type="bean.User"/> 
</typeAliases> 
<environments default="development"> 
«environment id="development"> 


<transactionManager type="jdbc"/> 


«dataSource type="POOLED"> 
<property name-"driver" value="com.mysql.jdbc.Driver"/> 
<property name="url" 
value="jdbc:mysql://localhost/lexueba"/> 
<property hame="username" value="root"/> 
<property name="password" value="haojia0421xixi"/> 
</dataSource> 
</environment> 
</environments> 
«mappers^ 
«mapper resource-"resource/UserMapper.xml" /> 
</mappers> 
</configuration> 
(4) 建立 映射 文件 。 
对 应 于 MyBaits 全 局 配置 中 的 mappers 配置 属性 ， 主 要 用 于 建立 
对 应 数据 库 操作 接口 的 SQL 映 射 。MyBatis 会 将 这 里 设 定 的 SQL 与 对 应 
的 Java 接 口 相 关联 ， 以 保证 在 MyBatis 中 调用 接口 的 时 候 会 到 数据 库 中 
执行 相应 的 SQL 来 简化 开发 。 
<?xml version="1.0" encoding="UTF-8" ?> 
<!DOCTY PE mapper 
PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN" 
"http://mybatis.org/dtd/mybatis-3-mapper.dtd"> 
<mapper namespace="Mapper.UserMapper"> 
<!-- 这 里 namespace 必须 是 UserMapper 接口 的 路 径 ， 不 然 要 运行 
的 时 候 要 报错 “is not known to the 
MapperRegistry”--> 


«insert id="insertUser" parameterType="User" > 


insert into user(name,age) values(#{name},#{age}) 
<!-- 这 里 sql 结 尾 不 能 加 分 号 ， 否 则 报 “ORA-00911” 的 错误 --> 
</insert> 
<!-- 这 里 的 id 必须 和 UserMapper 接 口中 的 接口 方法 名 相同 ， 不 
然 运行 的 时 候 也 要 报错 --> 
<select id="getUser" resultType="User" 
parameterType="java.lang.Integer" > 
select * from user where id=#{id} 
</select> 
</mapper> 
(5) 建立 测试 类 。 
至 此 我 们 已 经 完成 了 MyBatis 的 建立 过 程 ， 接 下 来 的 工作 就 是 对 之 
前 的 所 有 工作 进行 测试 ， 以 便 直接 查看 MyBatis 为 我 们 提供 的 效果 。 
public class MyBatisUtil { 
private final static SqlSessionFactory sqlSessionFactory; 
static 1 
String resource = "resource/mybatis-config.xml"; 
Reader reader = null; 
try { 
reader = Resources.getResourceAsReader(resource); 
} catch (IOException e) { 
System.out.println(e.getMessage()); 
i 
sqlSessionFactory = new 


SqlSessionFactoryBuilder().build(reader); 


} 
public static SqlSessionFactory getSqlSessionFactory() { 


return sqlSessionFactory; 


j 
public class TestMapper 1 
static SqlSessionFactory sqlSessionFactory = null; 
Static { 
sqlSessionFactory = MyBatisUtil.getSqlSessionFactory(); 
} 
@Test 
public void testAdd() { 
SqlSession sqlSession = sqlSessionFactory.openSession(); 
try { 
UserMapper userMapper = 
sqlSession.getMapper(UserMapper.class); 
User user = new User("tom",new Integer(5)); 
userMapper.insertUser(user); 
sqlSession.commit();// 这 里 一 定 要 提交 ， 不 然 数据 进 不 去 数 
据 库 中 
} finally { 


sqlSession.close(); 


} 
@Test 
public void getUser() { 


SqlSession sqlSession = sqlSessionFactory.openSession(); 


try { 


UserMapper userMapper = 
sqlSession.getMapper(UserMapper.class); 
User user = userMapper.getUser(1); 


System.out.printIn("name: "+user.getName()+" age: 
"+user.getA ge()); 


} finally { 
sqlSession.close(); 


} 


} 

注意 ， 这 里 在 数据 库 设 定 了 id 自 增 策略 ， 所 以 插入 的 数据 会 直接 
在 效 据 库 中 赋值 ， 当 执行 测试 后 如 果 数 据 表 为 空 ， 那 么 在 表 中 会 出 现 
一 条 我 们 插入 的 数据 ， 并 会 在 查询 时 将 此 数据 查 出 。 


9.2 Spring 整 合 MyBatis 


了 解 了 MyBatis 的 独立 使 用 过 程 后 ， 我 们 再 看 看 它 与 Spring 整合 的 
使 用 方式 ， 比 对 之 前 的 示例 来 找 出 Spring 究竟 为 我 们 做 了 哪些 操作 来 
简化 程序 员 的 业务 开 友 。 由 于 在 上 面 示例 基础 上 作 更 改 ， 所 以 ，User 
与 UserMapper 保 持 不 变 。 

(1) Spring 配置 文件 。 

配置 文件 是 Spring 的 核心 ，Spring 的 所 有 操作 也 都 是 由 配置 文件 开 
始 的 ， 所 以 ， 我 们 的 示例 也 首先 从 配置 文件 开始 。 

<?xml version="1.0" encoding="UTF-8"?> 

«beans xmlns-"http://www.Springframework.org/schema/beans" 


xmins:xsi-"http://www.w3.0rg/2001/XMLSchema-instance" 


xsi:schemaLocation="http://www.Springframework.org/schema/beans 
http://www. Springframework. 
org/ schema/beans/Spring-beans-3.0.xsd"> 
<bean id="dataSource" 
class="org.apache.commons.dbcp.BasicDataSource"> 
<property name="driverClassName" 
value="com.mysql.jdbc.Driver"></property> 
<property name="url" 
value="jdbc:mysql://localhost:3306/lexueba?useUnicode= 
true&amp;characterEncoding=UTF- 
8&amp;zeroDateTimeBehavior=convertToNull"></property> 
<property name-"username" value="root"></property> 
<property name="password" value="haojia0421xixi"> 
</property> 
<property name-"maxActive" value="100"></property> 
<property name="maxlIdle" value="30"></property> 
<property name="max Wait" value="500"></property> 
<property name-"defaultAutoCommit" value="true"> 
</property> 
</bean> 
<bean id="sqlSessionFactory" 
class="org.mybatis.Spring.SqlSessionFactoryBean"> 
<property name-"configLocation" 
value="classpath:test/mybatis/MyBatis-Configuration. 
xml"></property> 


<property name-"dataSource" ref-"dataSource" /> 


</bean> 
<bean id="userMapper" 
class="org.mybatis.Spring.mapper.MapperFactoryBean"> 
<property name-"mapperlInterface" 
value="test.mybatis.dao.UserMapper"></property> 
<property name="sqlSessionFactory" ref="sqlSessionFactory"> 
</property> 
</bean> 
</beans> 
对 比 之 前 独立 使 用 MyBatis 的 配置 文件 ， 我 们 发 现 ， 之 前 在 
environments 中 设置 的 dataSource 被 转移 到 了 Spring 的 核心 配置 文件 
中 管理 。 而 且 ， 针 对 于 MyBatis ， 注 册 了 
org.mybatis.Spring.SqlSessionFactoryBean 类 型 bean， 以 及 用 于 映射 接 
口 的 org.mybatis.Spring. mapper.MapperFactoryBean， 这 两 个 bean 的 作 
用 我 们 会 在 稍 后 分 析 。 
之 前 我 们 了 解 到 ，MyBatis 提供 的 配置 文件 包含 了 诸多 属性 ， 虽 
然 大 多 数 情况 我 们 都 会 保持 MyBatis 原 有 的 风格 ， 将 MyBatis 的 配置 文 
件 独 立 出 来 ， 并 在 Spring 中 的 org.mybatis.Spring. SqlSessionFactoryBean 
类 型 的 bean 中 通过 configLocation 属 性 引入 ， 但 是 ， 这 并 不 代表 Spring 
不 支持 直接 配置 。 以 上 面 示例 为 例 ， 你 完全 可 以 省 去 MyBatis- 
Configuration.xml， 而 将 其 中 的 配置 以 属性 的 方式 注入 到 
SqlSessionFactoryBean 中 ， 至 于 每 个 属性 名 称 以 及 用 法 ， 我 们 会 在 后 面 
的 章节 中 进行 详细 的 分 析 。 
(2) MyBatis 配 置 文件 。 
对 比 独立 使 用 MyBatis 时 的 配置 文件 ， 当 前 的 配置 文件 除了 移 除 
environments 配 置 外 并 没有 太 多 的 变化 。 


<?xml version="1.0" encoding="UTF-8" ?> 


«IDOCTYPE configuration PUBLIC "-//mybatis.org//DTD Config 
3.0//EN" 
"http://mybatis.org/dtd/mybatis-3-config.dtd" 
«configuration» 
<typeAliases> 
<typeAlias alias="User" type="test.mybatis.bean.User"/> 
</typeAliases> 
<mappers> 
«mapper resource="test/mybatis/UserMapper.xml"/> 
</mappers> 
</configuration> 
(3) 映射 文件 (保持 不 变 ) 。 
«?xml version="1.0" encoding="UTF-8" ?> 
<!DOCTYPE mapper PUBLIC "-//mybatis.org//DTD Mapper 
3.0//EN" "http://mybatis.org/ 
dtd/mybatis-3-mapper.dtd"> 
<mapper namespace="test.mybatis.dao.UserMapper"> 
«insert id="insertUser" parameterTIype-" User" > 
insert into user(name,age) values(#{name},#{age }) 
</insert> 
<select id="getUser" resultType-"User" 
parameterType="java.lang.String"” > 
select * from user where name=#{name} 
</select> 


</mapper> 


(4) 测试 。 


至 此 ， 我 们 已 经 完成 了 Spring 与 MyBatis 的 整合 ， 我 们 发 现 ， 对 于 
MyBatis 方 面 的 配置 文件 ， 除 了 将 dataSource 配 置 移 到 Spring 配置 文件 
中 管理 外 ， 并 没有 太 多 变化 ， 而 在 Spring 的 配置 文件 中 又 增加 了 用 于 
处 理 MyBatis 的 两 个 bean。 

Spring 整合 MyBatis 的 优势 主要 在 于 使 用 上 ， 我 们 来 看 看 Spring 中 
使 用 MyBatis 的 用 法 。 

public class UserServiceTest { 

public static void main(String[] args) { 
ApplicationContext context = new 
ClassPathXmlApplicationContext("test/ mybatis/ 
applicationContext.xml"); 
UserMapper userDao = 
(UserMapper)context.getBean("userMapper"); 
System.out.printIn(userDao.getUser(" 1")); 
} 

} 

测试 中 我 们 看 到 ， 在 Spring 中 使 用 MyBatis 非常 方便 ， 用 户 甚 至 
无 法 察觉 自己 正在 使 用 MyBatis， 而 这 一 切 相 对 于 独立 使 用 MyBatis 时 
必须 要 做 的 各 种 元 余 操 作 来 说 无 非 是 大 大 简化 了 我 们 的 工作 量 。 


9.3 源码 分 析 


通过 Spring 整合 MyBatis 的 示例 ， 我 们 感受 到 了 Spring 为 用 户 更 加 
快捷 地 进行 开发 所 做 的 努力 ， 开 发 人 员 的 工作 效率 由 此 得 到 了 显著 的 
提升 。 但 是 ， 相 对 于 使 用 来 说 ， 我 们 更 想 知 道 其 背后 所 隐藏 的 秘密 ， 
Spring 整合 MyBatis 是 何如 实现 的 呢 ? 通过 分 析 整 合 示例 中 的 配置 文 
件 ， 我 们 可 以 知道 配置 的 bean 其 实 是 成 树 状 结构 的 ， 而 在 树 的 最 顶层 


是 类 型 为 org.mybatis. Spring.SqlSessionFactoryBean 的 bean， 它 将 其 他 
相关 bean 组 装 在 了 一 起 ， 那 么 ， 我 们 的 分 析 就 从 此 类 开始 。 


9.3.1 sqlSessionFactory 创 建 


通过 配置 文件 我 们 分 析 ， 对 于 配置 文件 的 读 取 解析 ，Spring 应 该 
通过 org.mybatis.Spring.&nbsp;SgqlSessionFactoryBeant]Z& f MyBatisFH 
的 实现 。 我 们 进入 这 个 类 ， 首 先 查 看 这 个 类 的 层次 结构 ， 如 图 9-2 所 
示 。 根 据 这 个 类 的 层次 结构 找 出 我 们 感 兴 趣 的 两 个 接口 ， FactoryBean 


All InitializingBeano 


(2 

©  ApplicationListener«E» 
© EventListener 

Q FactoryBean«T* 

o 


InitializingBean 


图 9-2 SqlSessionFactoryBean 类 的 层次 结构 


InitializingBean: 实现 此 接口 的 bean 会 在 初始 化 时 调用 其 
afterPropertiesSet 方 法 来 进行 bean 的 逻辑 初始 化 。 

FactoryBean: 一 旦 某 个 bean 实 现 次 接口 ， 那 么 通过 getBean 方 法 获 
取 bean 时 其 实 是 获取 此 类 的 getObjectO 返 回 的 实例 。 

我 们 首先 以 InitializingBean 接 口 的 afterPropertiesSet() 方 法 作为 突破 
点 


JIWNO 


1. SqlSessionFactoryBean 的 初始 化 
查看 org.mybatis.Spring.SqlSessionFactoryBean 类 型 的 bean 在 初始 化 
时 做 了 哪些 逻辑 实现 。 


public void afterPropertiesSet() throws Exception { 


notNull(dataSource, "Property 'dataSource' is required"); 
notNull(sqlSessionFactoryBuilder, "Property 
'sqlSessionFactoryBuilder' is required"); 
this.sqlSessionFactory = buildSqlSessionFactory(); 
j 
很 显然 ， 此 函数 主要 目的 就 是 对 于 sqlSessionFactory 的 初始 化 ， 通 
过 之 前 展示 的 独立 使 用 MyBatis 的 示例 ， 我 们 了 解 到 SqlSessionFactory 
是 所 有 MyBatis 功 能 的 基础 。 
protected SqlSessionFactory buildSqlSessionFactory() throws 
IOException 1 
Configuration configuration; 
XMLConfigBuilder xmlConfigBuilder - null; 
if (this.configLocation != null) { 
xmlConfigBuilder = new 
XMLConfigBuilder(this.configLocation.getInputStream(), null, 
this.configurationProperties); 
configuration = xmlConfigBuilder.getConfiguration(); 
} else { 
if (this. logger.isDebugEnabled()) { 
this.logger.debug(" Property 'configLocation' not specified, 
using default MyBatis 
Configuration"); 
| 
configuration = new Configuration(); 
configuration.setVariables(this.configurationProperties); 


} 
if (this.objectFactory != null) { 


configuration.setObjectFactory(this.objectFactory); 


j 
if (this.objectWrapperFactory !- null) 1 


configuration.setObjectWrapperFactory(this.objectWrapperFactory); 
} 
if (hasLength(this.typeAliasesPackage)) { 
String[] typeAliasPackageArray = 
tokenizeToStringArray(this.typeAliasesPackage, 


ConfigurableApplicationContext. CONFIG LOCATION DELIMITERS); 
for (String packageToScan : typeAliasPackageArray) { 


configuration.getTypeAliasRegistry().registerA liases(packageToScan, 
typeAliasesSuperType == null ? Object.class : 
typeAliasesSuperType); 
if (this. logger.isDebugEnabled()) { 
this.logger.debug("Scanned package: " + packageToScan + 
™ for aliases"); 


} 


} 
if ('isEmpty(this.typeAliases)) { 
for (Class<?> typeAlias : this.typeAliases) 1 
configuration.getTypeAliasRegistry().registerAlias(typeAlias); 
if (this. logger.isDebugEnabled()) 1 


this.logger.debug(" Registered type alias: " + typeAlias + 


if ('isEmpty(this.plugins)) 1 
for (Interceptor plugin : this.plugins) { 
configuration.addInterceptor(plugin); 
if (this.logger.isDebugEnabled()) 1 
this.logger.debug( Registered plugin: " + plugin + """); 


j 
if (hasLength(this.typeHandlersPackage)) 1 
String[] typeHandlersPackageArray = 
tokenizeToStringArray(this.typeHandlersPackage, 


ConfigurableApplicationContext. CONFIG LOCATION DELIMITERS); 
for (String packageToScan : typeHandlersPackageArray) 1 


configuration.getTypeHandlerRegistry().register(packageToScan); 
if (this.logger.isDebugEnabled()) 1 
this.logger.debug(" Scanned package: " + packageToScan + ” 
for type handlers"); 
j 


if ('isEmpty(this.typeHandlers)) { 
for (TypeHandler<?> typeHandler : this.typeHandlers) 1 
configuration. get lypeHandlerRegistry().register(typeHandler); 
if (this.logger.isDebugEnabled()) { 
this.logger.debug(" Registered type handler: " + typeHandler + 


if (xmlConfigBuilder != null) 1 
try { 
xmlConfigBuilder.parse(); 
if (this.logger.isDebugEnabled()) 1 
this.logger.debug("Parsed configuration file: ' + 
this.configLocation + '"""); 
} 
} catch (Exception ex) { 
throw new NestedIOException("Failed to parse config resource: 
" + this. 
configLocation, ex); 
) finally { 


ErrorContext.instance().reset(); 


j 
if (this.transactionFactory == null) 1 


this.transactionFactory = new SpringManagedTransactionFactory(); 


Environment environment = new Environment(this.environment, 
this.transactionFactory, 
this.dataSource); 
configuration.setEnvironment(environment); 
if (this.databaseIdProvider != null) { 
try { 


configuration.setDatabaseld(this.databaseIdProvider.getDatabaseld 
(this.dataSource)); 
} catch (SQLException e) { 
throw new NestedIOException("Failed getting a databaseld", e); 


} 
if ('isEmpty(this.mapperLocations)) { 
for (Resource mapperLocation : this.mapperLocations) 1 
if (mapperLocation == null) { 
continue; 
j 
try { 
XMLMapperBuilder xmnlMapperBuilder = new 
XMLMapperBuilder(mapperLocation. 
getInputStream(), 
configuration, mapperLocation.toString(), 
configuration.getSqlFragments()); 
xmlMapperBuilder.parse(); 
} catch (Exception e) { 


十 po e); 


throw new NestedIOException(" Failed to parse mapping 
resource: " + mapperLocation 
} finally { 
ErrorContext.instance().reset(); 
} 
if (this. logger.isDebugEnabled()) { 


this.logger.debug("Parsed mapper file: " + mapperLocation + 


} else { 
if (this. logger.isDebugEnabled()) { 
this.logger.debug(" Property 'mapperLocations' was not specified 
or no matching 
resources found"); 
j 
j 
return this.sqlSessionFactoryBuilder.build(configuration); 
j 
从 函数 中 可 以 看 到 ， 尽 管 我 们 还 是 习惯 于 将 MyBatis 的 配置 与 
Spring 的 配置 独立 出 来 ， 但 是 ， 这 并 不 代表 Spring 中 的 配置 不 支持 直接 
配置 。 也 就 是 说 ， 在 上 面 提供 的 示例 中 ， 你 完全 可 以 取消 配置 中 的 
configLocation 属 性 ， 而 把 其 中 的 属性 直接 写 在 SqlSessionFactoryBean 
中 。 
<bean id="sqlSessionFactory" 


class="org.mybatis.Spring.SqlSessionFactoryBean"> 


«property name-"configLocation" 
value-"classpath:test/mybatis/MyBatis- Configuration. 
xml"></property> 
<property name-"dataSource" ref="dataSource" /> 
<property name="typeAliasesPackage" value="aaaaa"/> 
</bean> 
从 这 个 函数 中 可 以 得 知 ， 配 置 文件 还 可 以 支持 其 他 多 种 属性 的 配 
置 ， 如 configLocation、 objectFactory、 objectWrapperFactory、 
typeAliasesPackage, typeAliases, typeHandlersPackage, plugins, 
typeHandlers, transactionFactory、 databaseIdProvider、 
mapperLocationso 
其 实 ， 如 果 只 按照 音 用 的 配置 ， 那 么 我 们 只 需要 在 孙 数 最 开始 按 
照 如 下 方式 处 理 configuration : 
xmlConfigBuilder = new 
XMLConfigBuilder(this.configLocation.getInputStream(), null, 
this.configurationProperties); 
configuration = xmlConfigBuilder.getConfiguration(); 
根据 configLocation 构 造 XMLConfigBuilder 并 进行 解析 ， 但 是 ， 为 
了 体现 Spring 更 强大 的 兼容 性 ，Spring 还 整合 了 MyBatis 中 其 他 属性 的 
注入 ， 并 通过 实例 configuration 来 承载 每 一 步 所 获取 的 信息 并 最 终 使 用 
sqlSessionFactoryBuilder 实例 根据 解析 到 的 configuration 创建 
SqlSessionFactory 实 例 。 
2. 获取 SqlsessionFactoryBean 实 例 
由 于 SqlSessionFactoryBean 实 现 了 FactoryBean 接 口 ， 所 以 当 通 过 
getBean 方 法 获取 对 应 实例 时 ， 其 实 是 获取 该 类 的 getObject0 阔 数 返 回 
的 实例 ， 也 就 是 获取 初始 化 后 的 sqlSession Factory 属 性 。 


public SqlSessionFactory getObject() throws Exception 1 
if (this.sqlSessionFactory == null) { 
afterPropertiesSet(); 
return this.sqlSessionFactory; 
j 
d MapperFactoryBean 的 创建 
为 了 使 用 MyBatis 功能 ， 示 例 中 的 Spring 配置 文件 提供 了 两 个 
bean， 除 了 之 前 分 析 的 SqlSssionFactoryBean 类 型 的 bean 以 外 ， 还 有 一 
个 是 MapperFactoryBean 类 型 的 bean。 
结合 两 个 测试 用 例 综合 分 析 ， 对 于 单独 使 用 MyBatis 的 时 候 调 用 数 
据 库 接口 的 方式 是 : 
UserMapper userMapper = sqlSession.getMapper(UserMapper.class); 
而 在 这 一 过 程 中 ， 其 实 是 MyBatis 在 获取 映射 的 过 程 中 根据 配置 信 
息 为 UserMapper 类 型 动态 创建 了 代理 类 。 而 对 于 Spring 的 创建 方式 : 
UserMapper userMapper = 


(UserMapper)context.getBean("userMapper"); 

Spring 中 获取 的 名 为 userMapper 的 bean， 其 实 是 与 单独 使 用 
MyBatis 完成 了 一 样 的 功能 ， 那 么 我 们 可 以 推断 ， 在 bean 的 创建 过 程 
中 一 定 是 使 用 了 MyBatis 中 的 原生 方法 
sqlSession.getMapper(UserMapper.class) 进 行 了 骨 一 次 封装 。 结 合 配 置 
文件 ， 我 们 把 分 析 目 标 转向 org.mybatis.Spring.mapper. 
MapperFactoryBean， 初 步 推测 其 中 的 逻辑 应 该 在 此 类 中 实现 。 同 样 ， 
还 是 首先 查看 的 类 层次 结构 图 MapperFactoryBean， 如 图 9-3 所 示 。 


4 K9 MapperFactoryBean«T» 
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同样 ， 在 实现 的 接口 中 发 现 了 我 们 感 兴 趣 的 两 个 接口 
InitializingBean 与 FactoryBean。 我 们 的 分 析 还 是 从 bean 的 初始 化 开始 。 
1. MapperFactoryBean 的 初始 化 
为 实现 了 InitializingBean 接 口 ，Spring 会 保证 在 bean 初 始 化 时 首 
先 调用 afterPropertiesSet 方 法 来 完成 其 初始 化 逻辑 。 追 踪 父 类 ， 发 现 
afterPropertiesSet 方 法 是 在 DaoSupport 类 中 实现 ， 代 码 如 下 : 
public final void afterPropertiesSet() throws 
IllegalArgumentException, BeanInitialization 
Exception 1 
// Let abstract subclasses check their configuration. 
checkDaoConfig(); 
// Let concrete implementations initialize themselves. 
try { 
initDao(); 
} 
catch (Exception ex) { 
throw new BeanlnitializationException("Initialization of DAO 


failed", ex); 


j 
但 从 函数 名 称 来 看 我 们 大 体 推 测 ，MapperFactoryBean 的 初始 化 包 
括 对 DAO 配 置 的 验证 以 及 对 DAO 的 初始 工作 ， 其 中 initDao() 方 法 是 模 
板 方法 ， 设 计 为 留 给 子 类 做 进一步 逻辑 处 理 。 而 checkDaoConfig0) 才 是 
我 们 分 析 的 重点 。 
@Override 
protected void checkDaoConfig() { 
super.checkDaoConfig(); 
notNull(this.mapperInterface, "Property 'mapperInterface' is 
required"); 
Configuration configuration = 
getSqlSession().getConfiguration(); 
if (this.addToConfig && 
!configuration.hasMapper(this.mapperInterface)) { 
try { 
configuration.addMapper(this.mapperInterface); 
} catch (Throwable t) { 
logger.error("Error while adding the mapper ' + 
this.mapperlInterface + "' to 
configuration.", t); 
throw new Illegal ArgumentException(t); 
) finally 1 


ErrorContext.instance().reset(); 


super.checkDaoConfig() 在 SqlSessionDaoSupport 类 中 实现 ， 代 码 如 
iB: 
protected void checkDaoConfig() { 
notNull(this.sqlSession, "Property 'sqlSessionFactory' or 
'sqlSessionTemplate' are 
required"); 
j 
结合 代码 我 们 了 解 到 对 于 DAO 配 置 的 验证 ，Spring 做 了 以 下 几 个 
方面 的 工作 。 
父 类 中 对 于 sqlSession 不 为 空 的 验证 。 
sqlSession 作 为 根据 接口 创建 映射 器 代理 的 接触 类 一 定 不 可 以 为 
， 而 sqlSession 的 初始 化 工作 是 在 设 定 其 sqlSessionFactory 属 性 时 完成 
的 。 
public void setSqlSessionFactory(SqlSessionFactory 
sqlSessionFactory) 1 
if (!this.externalSqlSession) 1 


this.sqlSession = new SqlSessionTemplate(sqlSessionFactory); 


} 
也 就 是 说 ， 对 于 下 面 的 配置 如 果 忽略 了 对 于 sqlSessionFactory 属 性 
的 设置 ， 那 么 在 此 时 就 会 被 检测 出 来 。 
<bean id="userMapper" 
class="org.mybatis.Spring.mapper.MapperFactoryBean"> 
<property name-"mapperInterface" 
value="test.mybatis.dao.UserMapper"></property> 
<property name="sqlSessionFactory" ref="sqlSessionFactory"> 


</property> 


</bean> 

映射 接口 的 验证 。 

接口 是 映射 器 的 基础 ，sqlSession 会 根据 接口 动态 创建 相应 的 代理 
类 ， 所 以 接口 必 不 可 少 。 

映射 文件 存在 性 验证 。 

对 于 函数 前 半 部 分 的 验证 我 们 都 很 容易 理解 ， 无 非 是 对 配置 文件 
中 的 属性 是 否 存在 做 验证 ， 但 是 后 面部 分 是 完成 了 什么 方面 的 验证 
呢 ? 如 果 读 者 读 过 MyBatis 源码 ， 你 就 会 知道 ， 在 MyBatis 实 现 过 程 中 
并 没有 手动 调用 configuration.addMapper 方 法 ， 而 是 在 映射 文件 读 取 过 
程 中 一 旦 解析 到 如 <mapper namespace="Mapper.UserMapper"> ， 便 会 
自动 进行 类 型 映射 的 注册 。 那 么 ，Spring 中 为 什么 会 把 这 个 功能 单独 
拿 出 来 放 在 验证 里 呢 ? 这 是 不 是 多 此 一 举 呢 ? 

在 上 面 的 负数 中 ，configuration.addMapper(this.mapperInterface) 其 
实 就 是 将 UserMapper 注册 到 映射 类 型 中 ， 如 果 你 可 以 保证 这 个 接口 一 
定 存在 对 应 的 映射 文件 ， 那 么 其 实 这 个 验证 并 没有 必要 。 但 是 ， 由 于 
这 个 是 我 们 自行 决定 的 配置 ， 无 法 保证 这 里 配置 的 接口 一 定 存在 对 应 
的 映射 文件 ， 所 以 这 里 非常 有 必要 进行 验证 。 在 执行 此 代码 的 时 候 ， 
MyBatis 会 检查 岁入 的 映射 接口 是 否 存在 对 应 的 映射 文件 ， 如 果 没 有 
回 抛 出 异常 ，Spring 正 是 在 用 这 种 方式 来 完成 接口 对 应 的 映射 文件 存 
在 性 验证 。 

2。 获 取 MapperFactoryBean 的 实例 

由 于 MapperFactoryBean 实 现 了 FactoryBean 接 口 ， 所 以 当 通 过 
getBean 方 法 获取 对 应 实例 的 时 候 其 实 是 获取 该 类 的 getObject(0) 遂 数 返 
回 的 实例 。 

public T getObject() throws Exception { 

return getSqlSession().getMapper(this.mapperInterface); 


这 段 代 码 正 是 我 们 在 提供 MyBatis 独立 使 用 的 时 候 的 一 个 代码 调 
用 。Spring 通过 FactoryBean 进 行 了 封装 。 


9.3.3 MapperScannerConfigurer 


我 们 在 applicationContext.xml 中 配置 了 userMapper 供 需要 时 使 用 。 
但 如 果 需 要 用 到 的 映射 器 较 多 的 话 ， 采 用 这 种 配置 方式 就 显得 很 低 
效 。 为 了 解决 这 个 问题 ， 我 们 可 以 使 用 MapperScanner Configurer， 让 
它 扫描 特定 的 包 ， 自 动 帮 我 们 成 批 地 创建 映射 器 。 这 样 一 来 ， 就 能 
大 减少 配置 的 工作 量 ， 比 如 我 们 将 applicationContext.xml 文 件 中 的 配置 
改 成 如 下 : 

<?xml version="1.0" encoding="UTF-8"?> 

«beans xmlns="http://www.Springframework.org/schema/beans" 


xmins:xsi-"http://www.w3.0rg/2001/XMLSchema-instance" 


xsi:schemaLocation="http://www.Springframework.org/schema/beans 
http://www. Springframework. 
org/schema/beans/Spring-beans-3.0.xsd"> 
<bean id="dataSource" 
class="org.apache.commons.dbcp.BasicDataSource"> 
<property name="driverClassName" 
value="com.mysql.jdbc.Driver"></property> 
<property name="url" 
value="jdbc:mysql://localhost:3306/lexueba?useUnicode= 
true&amp;characterEncoding-UTF- 
8&amp;zeroDateTimeBehavior=convertToNull"></property> 


<property name-"username" value="root"></property> 


«property name-"password" value="haojia0421xixi"> 
</property> 
<property name-"maxActive" value="100"></property> 
<property name="maxlIdle" value="30"></property> 
<property name="max Wait" value="500"></property> 
<property name-"defaultAutoCommit" value="true"> 
</property> 
</bean> 
<bean id="sqlSessionFactory" 
class="org.mybatis.Spring.SqlSessionFactoryBean"> 
<property name-"configLocation" 
value="classpath:test/mybatis/MyBatis- Configuration. 
xml"></property> 
<property name-"dataSource" ref="dataSource" /> 
<property name-"typeAliasesPackage" value="aaaaa"/> 
</bean> 
<!-- 注释 掉 原 有 代码 
<bean id="userMapper" 
class="org.mybatis.Spring.mapper.MapperFactoryBean"> 
<property name="mapperlInterface" 
value="test.mybatis.dao.UserMapper"></property> 
<property name="sqlSessionFactory" ref="sqlSessionFactory"> 
</property> 
</bean> 
ads 
«bean 


class="org.mybatis.Spring.mapper.MapperScannerConfigurer"> 


«property name-"basePackage" value-"test.mybatis.dao" /> 
</bean> 

</beans> 

在 上 面 的 配置 中 ， 我 们 屏 贡 掉 了 最 原始 的 代码 (userMapper AYE! 
££) 而 增加 了 MapperScannerConfigurer 的 配置 ，basePackage 属性 是 让 
你 为 映射 器 接口 文件 设置 基本 的 包 路 径 。 你 可 以 使 用 分 号 或 逗号 作为 
分 隔 符 设置 多 于 一 个 的 包 路 径 。 每 个 映射 器 将 会 在 指定 的 包 路 径 中 递 
归 地 被 搜索 到 。 被 发 现 的 映射 器 将 会 使 用 Spring 对 上 自动 侦 测 组 件 默 认 
的 命名 策略 来 命名 。 也 就 是 说 ， 如 果 没 有 发 现 注 解 ， 它 就 会 使 用 映射 
器 的 非 大 写 的 非 完 全 限定 类 名 。 但 是 如 果 发 现 了 @Component 或 JSR- 
330@Named 注解 ， 它 会 获取 名 称 。 

通过 上 面 的 配置 ， Spring 融会 帮助 我 们 对 test. mybatis.dao 下 面 的 
所 有 接口 进行 自动 的 注入 ， 而 不 需要 为 每 个 接口 重复 在 Spring 配置 文 
件 中 进行 声明 了 。 那 么 ， 这 个 功能 又 是 如 何 做 到 的 呢 ? MapperScanner 
Configurer 中 又 有 哪些 核心 操作 呢 ? 同样 ， 首 先 查 看 类 的 层次 结构 图 ， 
如 图 9-4 所 示 。 


t [uH E- 
| a K9 MapperScannerConfigurer 
(9 Object 
4 © ApplicationContextAware 
@ Aware 
4 © BeanDefinitionRegistryPostProcessor 
© BeanFactoryPostProcessor 
4 © BeanNameAware 
Q Aware 
© InitializingBean 
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我 们 又 看 到 了 令 人 感 兴 趣 的 接口 InitializingBean， 马 上 查找 类 的 
afterPropertiesSet 方法 来 看 看 类 的 初始 化 逻辑 。 
public void afterPropertiesSet() throws Exception { 
notNull(this.basePackage, "Property 'basePackage' is required"); 
j 
很 遗憾 ， 分 析 并 没有 想 我 们 之 前 那样 顺利 ，afterPropertiesSet() 方 
法 除了 一 句 对 basePackage 属 性 的 验证 代码 外 并 没有 太 多 的 逻辑 实现 。 
好 吧 ， 让 我 们 回 过 头 再 次 查看 MapperScanner Configurer 类 层次 结构 图 
中 感 兴 趣 的 接口 。 于 是 ， 我 们 发 现 了 
BeanDefinitionRegistryPostProcessor 与 BeanFactoryPostProcessor， 
Spring 在 初始 化 的 过 程 中 同样 会 保证 这 两 个 接口 的 调用 。 
首先 查看 MapperScannerConfigurer 类 中 对 于 
BeanFactoryPostProcessor 接 口 的 实现 : 
public void 
postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) { 
// left intentionally blank 
} 
没有 任何 逻辑 实现 ， 只 能 说 明 我 们 找 错 地 方 了 ， 继 续 找 ， 查 看 
MapperScannerConfigurer 类 中 对 于 BeanDefinitionRegistryPostProcessor 
接口 的 实现 。 
public void 
postProcessBeanDefinitionRegistry(BeanDefinitionRegistry registry) 
throws 
BeansException 1 
if (this.processPropertyPlaceHolders) 1 
processPropertyPlaceHolders(); 


ClassPathMapperScanner scanner = new 
ClassPathMapperScanner(registry); 
scanner.setAddToConfig(this.addToConfig); 
scanner.setAnnotationClass(this.annotationClass); 
scanner.setMarkerInterface(this.markerInterface); 
scanner.setSglSessionFactory(this.sqlSessionFactory); 


scanner.setSqlSessionTemplate(this.sqlSession Template); 


scanner.setSqlSessionFactoryBeanName(this.sqlSessionFactoryBeanName) 


5 


scanner.setSqlSessionTemplateBeanName(this.sqlSessionTemplateBeanNa 


me); 
scanner.setResourceLoader(this.applicationContext); 
scanner.setBeanNameGenerator(this.nameGenerator); 
scanner.registerFilters(); 
scanner.scan(StringUtils.tokenizeToStringArray(this.basePackage, 
Configurable 


ApplicationContext.CONFIG LOCATION DELIMITERS)); 

j 

Bingo! 这 次 找 对 地 方 了 。 大 致 看 一 下 代码 实现 ， 正 是 完成 了 对 指 
定 路 径 扫 描 的 逻辑 。 那 么 ， 我 们 就 以 此 为 入 口 ， 详 细 地 分 析 
MapperScannerConfigurer 所 提供 的 逻辑 实现 。 

1。processPropertyPlaceHolders 属 性 的 处 理 

首先 ， 难 题 就 是 processPropertyPlaceHolders 属 性 的 处 理 。 或 许 读 
者 并 未 过 多 接触 此 属性 ， 我 们 只 能 查看 processPropertyPlaceHolders() 也 | 
数 来 反 推 此 属性 所 代表 的 功能 。 


[# 
* BeanDefinitionRegistries are called early in application startup, 
before 
* BeanFactoryPostProcessors. This means that 
PropertyResourceConfigurers will not have been 
* loaded and any property substitution of this class' properties will 
fail. To avoid 
this, find 
* any PropertyResourceConfigurers defined in the context and run 
them on this class' bean 
* definition. Then update the values. 
2 
private void processPropertyPlaceHolders() 1 
Map<String, PropertyResourceConfigurer> prcs = 
applicationContext.getBeansOfType 
(PropertyResourceConfigurer.class); 
if (!prcs.isEmpty() && applicationContext instanceof 
GenericApplicationContext) { 
BeanDefinition mapperScannerBean = 
((GenericApplicationContext) applicationContext) 
.getBeanFactory().getBeanDefinition(beanName); 
// PropertyResourceConfigurer does not expose any methods to 
explicitly perform 
// property placeholder substitution. Instead, create a 
BeanFactory that just 


// contains this mapper scanner and post process the factory. 


DefaultListableBeanFactory factory = new 
DefaultListableBeanFactory(); 

factory.registerBeanDefinition(beanName, mapperScannerBean); 

for (PropertyResourceConfigurer prc : prcs.values()) 1 

prc.postProcessBeanFactory(factory); 

} 

Property Values values = 
mapperScannerBean.getProperty Values(); 

this.basePackage = updateProperty Value("basePackage", values); 

this.sqlSessionFactoryBeanName = 
updateProperty Value(" sqlSessionFactory BeanName", 

values); 

this.sqlSessionTemplateBeanName = 
updateProperty Value("sqlSessionTemplateBeanName", 


values); 


} 

不 知 读者 是 否 悟 出 了 此 函数 的 作用 呢 ? 或 许 此 函数 的 说 明 会 给 我 
们 一 些 提 示 : BeanDefinitionRegistries 会 在 用 启动 的 时 候 调 用 ， 并 且 
会 早 于 BeanFactoryPostProcessors 的 调用 ， 这 就 意味 着 
PropertyResourceConfigurers 还 没有 被 加 载 所 有 对 于 属性 文件 的 引用 将 
会 失效 。 法 手动 地 找 出 定义 的 
PropertyResourceConfigurers 并 进 行 提 前 调用 以 保证 对 于 属性 的 引用 可 
以 正音 工作 。 

我 想 读 者 已 经 有 所 感悟 ， 结 合 之 前 讲 过 的 
PropertyResourceConfigurer 的 用 法 ， 举 例 说 明 一 下 ， 如 要 创建 配置 文 
件 如 test.properties， 并 添加 属性 对 : 


` Yi 


basePackage-test.mybatis.dao 
然后 在 Spring 配置 文件 中 加 入 属性 文件 解析 器 : 
<bean id-"mesHandler" 
class-"org.Springframework.beans.factory.config.Property Placeholder 
Configurer" 
«property name-" locations" 
<list> 
<value>config/test.properties</value> 
</list> 
</property> 
</bean> 
修改 MapperScannerConfigurer 类 型 的 bean 的 定义 : 
<bean class="org.mybatis.Spring.mapper.MapperScannerConfigurer"> 
<property name-"basePackage" value="${basePackage }" /> 
</bean> 
此 时 你 会 发 现 ， 这 个 配置 并 没有 达到 预期 的 效果 ， 因 为 在 解析 
${basePackage} 的 J'ai DUM qudd 不 没有 被 调用 ， 也 
就 是 属性 文件 中 的 属性 还 没有 加 载 至 内 存 中 ， Spring 还 不 能 直接 使 用 
它 。 为 了 解决 这 个 问题 ，Spring 提 供 了 processPropertyPlaceHolders 属 
性 ， 你 需要 这 样 配 置 MapperScannerConfigurer 类 型 的 bean。 
<bean class="org.mybatis.Spring.mapper.MapperScannerConfigurer"> 
<property name="basePackage" value="test.mybatis.dao" /> 
<property name-"processPropertyPlaceHolders" value="true" /> 
</bean> 
通过 processPropertyPlaceHolders 属 性 的 配置 ， 将 程序 引入 我 们 正 
在 分 析 的 processProperty PlaceHolders 为 数 中 来 完成 属性 文件 的 加 载 。 


至 此 ， 我 们 终于 理 清 了 这 个 属性 的 作用 ， 再 次 回顾 这 个 函数 所 做 的 事 
情 。 
(1) 找到 所 有 已 经 注册 的 PropertyResourceConfigurer 类 型 的 
beano 
(2) 模拟 Spring 中 的 环境 来 用 处 理 器 。 这 里 通过 使 用 new 
DefaultListableBeanFactory() 来 模拟 Spring 中 的 环境 (完成 处 理 器 的 调 
用 后 便 失效 ) ， 将 映射 的 bean， 也 就 是 MapperScanner Configurer 类 型 
bean 注 册 到 环境 中 来 进行 后 理 器 的 调用 ， 处 理 器 
PropertyPlaceholderConfigurer 调 用 完成 的 功能 ， 即 找 出 所 有 bean 中 应 
用 属性 文件 的 变量 并 替换 。 也 就 是 说 ， 在 处 理 器 调用 后 ， 模 拟 环境 中 
模拟 的 MapperScannerConfigurer 类 型 的 bean 如 果 有 引入 属性 文件 中 的 
属性 那么 已 经 被 替换 了 ， 这 时 ， 表 将 模拟 bean 中 相关 的 属性 提取 出 来 
应 用 在 真实 的 bean 中 。 
2. 根据 配置 属性 生成 过 滤器 
在 postProcessBeanDefinitionRegistry 方 法 中 可 以 看 到 ， 配 置 中 支持 
很 多 属性 的 设 定 ， 但 是 我 们 感 兴趣 的 或 者 说 影响 扫描 结果 的 并 不 多 ， 
属性 设置 后 通过 在 scanner.registerFilters() 代 码 中 生成 对 应 的 过 滤器 来 
控制 扫 摘 结果 。 
public void registerFilters() 1 
boolean acceptAllIInterfaces = true; 
/对 于 annotationClass 属 性 的 处 理 
if (this.annotationClass !- null) { 
addIncludeFilter(new 
AnnotationTypeFilter(this.annotationClass)); 
acceptAllInterfaces = false; 
} 
/对 于 markerInterface 属 性 的 处 理 


if (this.markerInterface != null) { 


addIncludeFilter(new AssignableTypeFilter(this.markerInterface) 


@Override 
protected boolean matchClassName(String className) { 
return false; 
} 
y 
acceptAllInterfaces = false; 
} 
if (acceptAllInterfaces) { 
// default include filter that accepts all classes 
addIncludeFilter(new TypeFilter() 1 
public boolean match(MetadataReader metadataReader, 
MetadataReaderFactory metadata 
ReaderFactory) throws IOException { 


return true; 


y 
j 
// 不 扫描 package-info.java 文 件 
addExcludeFilter(new TypeFilter() { 
public boolean match(MetadataReader metadataReader, 
MetadataReaderFactory metadata 
ReaderFactory) throws IOException 1 
String className = 


metadataReader.getClassMetadata().getClassName(); 


return className.endsWith("package-info"); 
} 
y 
} 
代码 中 得 知 ， 根 据 之 前 属性 的 配置 生成 了 对 应 的 过 滤器 。 
(1) annotationClass 属 性 处 理 。 

如 果 annotationClass 不 为 空 ， 表 示 用 户 设 置 了 此 属性 ， 那 么 就 要 根 
据 此 属性 生成 过 滤器 以 保证 达到 用 户 想 要 的 效果 ， 而 封装 此 属性 的 过 
滤器 就 是 AnnotationTypeFilter。 Annotation TypeFilter 保 证 在 扫描 对 应 
Java 文 件 时 只 接受 标记 有 注解 为 annotationClass 的 接口 。 

(2) markerInterface 属 性 处 理 。 

如 果 markerInterface 不 为 空 ， 表 示 用 户 设置 了 此 属性 ， 那 么 就 要 根 
据 此 属性 生成 过 滤器 以 保证 达到 用 户 想 要 的 效果 ， 而 封 对 此 属性 的 过 
滤器 就 是 实现 AssignableTypeFilter 接口 的 局 部 类 。 表 示 扫 描 过 程 中 只 
有 实现 markerInterface 接 口 的 接口 才 会 被 接受 。 

(3) 全 局 默认 处 理 。 

在 上 面 两 个 属性 中 如 果 存 在 其 中 任何 属性 ，acceptAllInterfaces 的 
值 将 会 变 改 变 ， 但 是 如 果 用 户 没 有 设 定 以 上 两 个 属性 ， 那 么 ，Spring 
会 为 我 们 增加 一 个 默认 的 过 滤器 实现 TypeFilter 接 口 的 局 部 类 ， 旨 在 接 
受 所 有 接口 文件 。 

(4) package-info.java 处 理 。 

对 于 命名 为 package-info 的 Java 文 件 ， 默 认 不 作为 逻辑 实现 接 
口 ， 将 其 排除 掉 ， 使 用 TypeFilter 接 口 的 局 部 类 实现 match 方 法 。 

从 上 面 的 函数 我 们 看 出 ， 控 制 扫 摘 文件 Spring 通过 不 同 的 过 滤器 
完成 ， 这 些 定 义 的 过 滤器 记录 在 了 includeFilters 和 excludeFilters 属 性 
中 。 

public void addIncludeFilter( TypeFilter includeFilter) 1 


this.includeFilters.add(includeFilter); 
j 
public void addExcludeFilter(TypeFilter excludeFilter) 1 
this.excludeFilters.add(0, excludeFilter); 
j 
至 于 过 滤器 为 什么 会 在 扫描 过 程 中 起 作用 ， 我 们 在 讲解 扫描 实现 
时 候 再 继续 深入 研究 。 
3. 扫描 Java 文 件 
设置 了 相关 属性 以 及 生成 了 对 应 的 过 滤器 后 便 可 以 进行 文件 的 扫 
苗 了 ， 扫 描 工作 是 由 ClassPathMapperScanner 类 型 的 实例 scanner 中 的 
scan 方 法 完成 的 。 
public int scan(String... basePackages) { 
int beanCountAtScanStart = this.registry.getBeanDefinitionCount(); 
doScan(basePackages); 
/如 果 配 置 了 includeAnnotationConfig， 则 注册 对 应 注解 的 处 理 器 
以 保证 注解 功能 的 正 党 使 用 。 
if (this.includeAnnotationConfig) { 


AnnotationConfigUtils.registerAnnotationConfigProcessors(this.registry); 
j 
return this.registry.getBeanDefinitionCount() - 
beanCountAtScanStart; 
j 
scan 是 个 全 局 方法 ， 扫 描 工 作 通 过 doScan(basePackages) 委 托 给 了 
doScan 方 法 ， 同 时 ， 还 包括 了 includeAnnotationConfig 属 性 的 处 理 ， 
AnnotationConfigUtils.registerAnnotation ConfigProcessors (this.registry) 


代码 主要 是 完成 对 于 注解 处 理 器 的 简单 注册 ， 比 如 


AutowiredAnnotationBeanPost Processor, 
RequiredAnnotationBeanPostProcessor 等 ， 这 里 不 再 缆 述 ， 我 们 重点 研 
究 文 件 扫描 功能 的 实现 。 
ClassPathMapperScanner.java 
public Set<BeanDefinitionHolder> doScan(String... basePackages) { 
Set<BeanDefinitionHolder> beanDefinitions = 
super.doScan(basePackages); 
if (beanDefinitions.isEmpty()) { 
/如 果 没 有 扫描 到 任何 文件 发 出 警告 
logger.warn("No MyBatis mapper was found in " + 
Arrays.toString(basePackages) + ” 
package. Please check your configuration."); 
} else { 
for (BeanDefinitionHolder holder : beanDefinitions) { 
GenericBeanDefinition definition = (GenericBeanDefinition) 
holder.getBeanDefinition(); 
if (logger.isDebugEnabled()) 1 
logger.debug(" Creating MapperFactoryBean with name " + 
holder.getBeanName() 
* " and ™ + definition.getBeanClassName() + ” 
mapperlInterface"); 
j 
/开始 构造 MapperFactoryBean 类 型 的 bean. 
definition.getProperty Values().add(" mapperlInterface", 
definition.getBeanClassName()); 


definition.setBeanClass(MapperFactoryBean.class); 


definition.getProperty Values().add(" add ToConfig", 
this.add ToConfig); 
boolean explicitFactoryUsed - false; 
if (StringUtils.hasText(this.sqlSessionFactoryBeanName)) 1 
definition.getProperty Values().add(" sqlSessionFactory", new 
RuntimeBeanReference 
(this.sqlSessionFactoryBeanName)); 
explicitFactoryUsed - true; 
} else if (this.sqlSessionFactory != null) { 
definition.getProperty Values().add("sqlSessionFactory", 
this.sqlSessionFactory); 
explicitFactoryUsed = true; 
} 
if (StringUtils.hasText(this.sqlSessionTemplateBeanName)) { 
if (explicitFactoryUsed) 1 
logger.warn(" Cannot use both: sqlSessionTemplate and 
sqlSessionFactory together. 
sqlSessionFactory is ignored."); 
j 
definition.getProperty Values().add(" sqlSessionTemplate", new 
RuntimeBeanReference 
(this.sqlSessionTemplateBeanName)); 
explicitFactoryUsed = true; 
} else if (this.sqlSessionTemplate != null) 1 
if (explicitFactoryUsed) { 
logger.warn(" Cannot use both: sqlSessionTemplate and 


sqlSessionFactory together. 


sqlSessionFactory is ignored."); 
j 
definition.getProperty Values().add("sqlSessionTemplate", 
this.sqlSessionTemplate); 
explicitFactoryUsed - true; 
j 
if (lexplicitFactoryUsed) 1 
if (logger.isDebugEnabled()) 1 
logger.debug(" Enabling autowire by type for 
MapperFactoryBean with name ™ + 


holder.getBeanName() + '"."); 


definition.setAutowireMode(AbstractBeanDefinition.AUTOWIRE BY TY 
PE); 


j 

此 时 ， 虽 然 还 没有 完成 介绍 到 扫描 的 过 程 ， 但 是 我 们 也 应 该 理解 
了 Spring 中 对 于 自动 扫描 的 注册 ， 声 明 MapperScannerConfigurer 类 型 
的 bean 目的 是 不 需要 我 们 对 于 每 个 接口 都 注册 一 个 
MapperFactoryBean 类 型 的 对 应 的 bean， 但 是 ， 不 在 配置 文件 中 注册 
并 不 代表 这 个 bean 不 存在 ， 而 是 在 扫描 的 过 程 中 通过 编码 的 方式 动态 
注册 。 实 现 过 程 我 们 在 上 面 的 肖 数 中 可 以 看 得 非常 清楚 。 


protected Set<BeanDefinitionHolder> doScan(String... basePackages) 


Assert.notEmpty(basePackages, "At least one base package must be 
specified"); 
Set<BeanDefinitionHolder> beanDefinitions = new LinkedHashSet 
«BeanDefinition 
Holder>(); 
for (String basePackage : basePackages) { 
/扫描 basePackage 路 径 下 java 文 件 
Set<BeanDefinition> candidates = 
findCandidateComponents(basePackage); 
for (BeanDefinition candidate : candidates) { 
/解析 scope 属 性 
ScopeMetadata scopeMetadata = 
this.scopeMetadataResolver.resolveScopeMetadata 
(candidate); 
candidate.setScope(scopeMetadata.getScopeName()); 
String beanName = 
this.beanNameGenerator.generateBeanName(candidate, 
this.registry); 
if (candidate instanceof AbstractBeanDefinition) { 


postProcessBeanDefinition((AbstractBeanDefinition) 


candidate, 
beanName); 
} 
if (candidate instanceof AnnotatedBeanDefinition) { 
/如 果 是 AnnotatedBeanDefinition 类 型 的 bean, 需 要 检测 
下 常用 注解 如 : 


Primary、Lazy 等 


AnnotationConfigUtils.processCommonDefinitionAnnotations 
(CAnnotatedBeanDefinition) candidate); 
j 
/检测 当前 bean 是 否 已 经 注册 
if (checkCandidate(beanName, candidate)) 1 
BeanDefinitionHolder definitionHolder = new 
BeanDefinitionHolder 
(candidate, beanName); 
/如 果 当 前 bean 是 用 于 生成 代理 的 bean 那 么 需要 进一步 处 
理 


definitionHolder = 


AnnotationConfigUtils.applyScopedProxyMode(scopeMetadata, 
definitionHolder, this.registry); 
beanDefinitions.add(definitionHolder); 


registerBeanDefinition(definitionHolder, this.registry); 


j 
return beanDefinitions; 
} 
public Set<BeanDefinition> findCandidateComponents(String 
basePackage) 1 
Set<BeanDefinition> candidates = new 
LinkedHashSet<BeanDefinition>(); 
try { 


String packageSearchPath = ResourcePatternResolver. 
CLASSPATH ALL URL. 
PREFIX + 
resolveBasePackage(basePackage) + "/" + this.resourcePattern; 
Resource[] resources = this.resourcePatternResolver.getResources 
(package 
SearchPath); 
boolean traceEnabled = logger.isTraceEnabled(); 
boolean debugEnabled = logger.isDebugEnabled(); 
for (Resource resource : resources) ( 
if (traceEnabled) { 
logger.trace(" Scanning " + resource); 
j 
if (resource.isReadable()) 1 
try 1 
MetadataReader metadataReader = 
this.metadataReaderFactory. 
getMetadataReader(resource); 
if (isCandidateComponent(metadataReader)) 1 
ScannedGenericBeanDefinition sbd = new 
ScannedGenericBean 
Definition(metadataReader); 
sbd.setResource(resource); 
sbd.setSource(resource); 
if (isCandidateComponent(sbd)) { 
if (debugEnabled) { 


logger.debug("Identified candidate component 


class: " + resource); 
j 
candidates.add(sbd); 
j 
else { 
if (debugEnabled) { 
logger.debug("Ignored because not a concrete 


top-level class: " + resource); 


j 
else { 
if (traceEnabled) ( 
logger.trace("Ignored because not matching any 


filter: " + resource); 


j 
catch (Throwable ex) 1 
throw new BeanDefinitionStoreException( 
"Failed to read candidate component class: " + resource, 


ex); 


else { 
if (traceEnabled) ( 


logger.trace(" Ignored because not readable: " + resource); 


catch (IOException ex) 1 
throw new BeanDefinitionStoreException("I/O failure during 
classpath 
scanning", ex); 
j 
return candidates; 
} 
findCandidateComponents 方法 根据 传 入 的 包 路 径 信 息 并 结合 类 文 
件 路 径 拼 接 成 文件 的 绝对 路 径 ， 同 时 完成 了 文件 的 扫描 过 程 并 且 根 据 
对 应 的 文件 生成 了 对 应 的 bean ， 使 用 ScannedGenericBeanDefinition 类 
型 的 bean 承 载 信息 ，bean 中 只 记录 了 resource 和 source 人 信息。 这 里 ， 我 
们 更 感 兴趣 的 是 isCandidateComponent(metadataReader)， 此 句 代 码 用 于 
判断 当前 扫描 的 文件 是 否 符合 要 求 ， 而 我 们 之 前 注册 的 一 些 过 滤器 信 
息 也 正 是 在 此 时 派 上 用 场 的 。 
protected boolean isCandidateComponent(MetadataReader 
metadataReader) throws IOException { 
for (TypeFilter tf : this.excludeFilters) ( 
if (tf.match(metadataReader, this.metadataReaderFactory)) 1 


return false; 


j 
for (TypeFilter tf : this.includeFilters) 1 
if (tf.match(metadataReader, this.metadataReaderFactory)) 1 


AnnotationMetadata metadata = 
metadataReader.getAnnotationMetadata(); 
if (!metadata.isAnnotated(Profile.class.getName())) 1 
return true; 
j 
AnnotationAttributes profile = 
MetadataUtils.attributesFor(metadata, 
Profile.class); 
return 
this.environment.acceptsProfiles(profile.getStringArray("value")); 
j 
} 
return false; 
j 
我 们 看 到 了 之 前 加 入 过 滤器 的 两 个 属性 excludeFilters、 
includeFilters， 并 且 知 道 对 应 的 文件 是 否 符合 要 求 是 根据 过 滤器 中 的 
match 方 法 所 返回 的 信息 来 判断 的 ， 当 然 用 户 可 以 实现 并 注册 满足 自己 
业务 逻辑 的 过 滤器 来 控制 扫描 的 结果 ，metadataReader 中 有 你 过 滤 所 
需要 的 全 部 文件 信息 。 至 此 ， 我 们 完成 了 文件 的 扫描 过 程 的 分 析 。 


第 10 章 事务 


Spring 声 明 式 事务 让 我 们 从 复杂 的 事务 处 理 中 得 到 解脱 ， 使 我 们 
再 也 不 需要 去 处 理 获 得 连接 、 关 闭 连接 、 事 务 提交 和 回 滚 等 操作 ， 再 
也 不 需要 在 与 事务 相关 的 方法 中 处 理 大 量 的 try...catch...finally 代 码 。 
Spring 中 事务 的 使 用 虽然 已 经 相对 简单 得 多 ， 但 是 ， 还 是 有 很 多 的 使 


用 及 配置 规则 ， 有 兴趣 的 读者 可 以 目 己 查阅 相关 资料 进行 深 
里 只 列举 出 最 常用 的 使 用 方法 。 
同样 ， 我 们 还 是 以 最 简单 的 示例 来 进行 直观 地 介绍 。 


10.1 JDBCHT VARY 


(1) 创建 数据 表 结构 。 
CREATE TABLE user ( 
id int(11) NOT NULL auto_increment, 
'name' varchar(255) default NULL, 
'age' int(11) default NULL, 
'sex' varchar(255) default NULL, 
PRIMARY KEY (‘id’) 
) ENGINE-InnoDB DEFAULT CHARSET-utf8; 
(2) 创建 对 应 数据 表 的 PO。 
public class User { 
private int id; 
private String name; 
private int age; 
private String sex; 
// 省 略 set/get 方 法 
} 
(3) 创建 表 与 实体 间 的 映射 。 
public class UserRowMapper implements RowMapper { 
@Override 
public Object mapRow(ResultSet set, int index) throws 
SQLException { 


Set 


User person = new User(set.getInt("id"), set.getString(" name"), 


.getInt(" age"), set.getString("sex")); 


return person; 


j 
(4) 创建 数据 操作 接口 。 
@Transactional(propagation=Propagation.REQUIRED) 
public interface UserService { 
public void save(User user) throws Exception; 
} 
(5) 创建 数据 操作 接口 实现 类 。 
public class UserServiceImpl implements UserService { 
private JdbcTemplate jdbcTemplate; 
/ 设置 数据 源 
public void setDataSource(DataSource dataSource) { 
this.jdbcTemplate = new JdbcTemplate(dataSource); 
j 
public void save(User user) throws Exception 1 


jdbcTemplate.update( "insert into 


user(name,age,sex)values(?,?,?)", 


new Object[] { user.getName(), user.getAge(), 
user.getSex() }, new int[] { java.sql. Types. VARCHAR, 
java.sql. Types. INTEGER, java.sql.Types. VARCHAR }); 
// 事 务 测试 ， 加 上 这 人 句 代码 则 数据 不 会 保存 到 数据 库 中 


throw new RuntimeException("aa"); 


j 
(6) 创建 Spring 配置 文件 。 
<?xml version="1.0" encoding="UTF-8"?> 
«beans xmlns="http://www.Springframework.org/schema/beans" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xmlns:tx="http://www.Springframework.org/schema/tx" 
xmins:context-"http://www.Springframework.org/schema/context" 
xsi:schemaLocation=" 
http://www.Springframework.org/schema/beans 
http://www. Springframework. 
org/schema/beans/Spring-beans-2.5.xsd 
http://www. Springframework.org/schema/context 
http://www. Springframework. 
org/schema/context/Spring-context-2.5.xsd 
http://www.Springframework.org/schema/tx 
http://www. Springframework.org/ 
schema/tx/Spring-tx-2.5.xsd 
"> 
«tx:annotation-driven transaction-manager- 'transactionManager" 
/> 


<bean id="transactionManager" 


class-"org.Springframework.jdbc.datasource.DataSourceTransactionManag 
er"> 
«property name-"dataSource" ref="dataSource" /> 
</bean> 


<!-- 配 置 数据 产 --> 


<bean id="dataSource" 
class="org.apache.commons.dbcp.BasicDataSource" 
destroy-method="close"> 
<property name="driverClassName" 
value-"com.mysgl.jdbc.Driver" /> 
<property name="url" 
value="jdbc:mysql://localhost:3306/lexueba" /> 
<property name-"username" value="root" /> 
<property name="password" value="haojia0421xixi" /> 
<!-- 连 接 池 启 动 时 的 初始 值 --> 
«property name="initialSize" value="1" /> 
<!-- 连 接 闻 的 最 大 值 --> 
<property name="maxActive" value="300" /> 
<!-- 最 大 空 闪 值 . 当 经 过 一 个 高 峰 时 间 后 ， 连 接 池 可 以 慢 慢 将 
已 经 用 不 到 的 连接 慢 慢 释放 一 部 分 ， 一 直 减 
少 到 maxIdle 为 止 --> 
<property name="maxlIdle" value="2" /> 
«1--8/ | SAE. SAAR) FR BRT, EER Ma 
申请 去 一 些 连接 ， 以 免 洪 峰 来 时 来 不 及 申请 --> 
<property name='"minIdle" value="1" /> 
</bean> 
<!-- 配 置业 务 bean: PersonServiceBean --> 
<bean id="userService" class="service.UserServiceImpl"> 
<!-- 向 属性 dataSource 注 入 数据 源 --> 
«property name-"dataSource" ref="dataSource"></property> 
</bean> 


</beans> 


(7) 测试 。 
public static void main(String[] args) throws Exception { 
ApplicationContext act = new 
ClassPathXmlApplicationContext("bean.xml"); 
UserService userService = (UserService) 
act.getBean("userService"); 
User user = new User(); 
user.setName("5K — ccc"); 
user.setA ge(20); 
user.setSex(" E"); 
/ 保存 一 条 记录 
userService.save(user); 
j 
j 
上 面 的 测试 示例 中 ，UserServiceImpl 类 对 接口 UserService 中 的 save 
函数 的 实现 最 后 加 入 了 一 句 抛 出 异常 的 代码 : throw new 
RuntimeException("aa")。 当 注 掉 这 段 代 码 执行 测试 类 ， 那 么 会 看 到 数 
据 被 成 功 的 保存 到 了 数据 库 中 ， 但 是 如 果 加 入 这 段 代 码 时 再 次 运行 测 
试 类 ， 发 现 此 处 的 操作 并 不 会 将 数据 保存 到 数据 库 中 。 
注意 默认 情况 下 Spring 中 的 事务 处 理 只 对 RuntimeException 方 法 进 
行 回 滚 ， 所 以 ， 如 果 此 处 将 RuntimeException 替 换 成 普通 的 Exception 
会 产生 回 滚 效 果 。 


10.2 X Tn 


对 于 Spring 中 事务 功能 的 代码 分 析 ， 我 们 首先 从 配置 文件 开始 入 
手 ， 在 配置 文件 中 有 这 样 一 个 配置 : <tx:annotation-driven />。 可 以 说 


此 处 配置 是 事务 的 开关 ， 如 果 没 有 此 处 配置 ， 那 么 Spring 中 将 不 存在 
事务 的 功能 。 那 么 我 们 就 从 这 个 配置 开始 分 析 。 

根据 之 前 的 分 析 ， 我 们 因此 可 以 判断 ， 在 自 定 义 标 签 中 的 解析 过 
程 中 一 定 是 做 了 一 些 辅 助 操作 ， 于 是 我 们 先 从 自 定义 标签 入 手 进 行 分 
析 。 


- 


使 用 Eclipse 搜索 全 局 代码 ， 关 键 字 annotation-drive， 最 终 锁 定 类 
TxNamespaceHandler， 在 TxNamespaceHandler 中 的 init 方 法 中 : 
public void init() 1 
registerBeanDefinitionParser(" advice", new 
TxAdviceBeanDefinitionParser()); 
registerBeanDefinitionParser("annotation-driven", new 
AnnotationDrivenBean 
DefinitionParser()); 
registerBeanDefinitionParser("jta-transaction-manager", new 
JtaTransactionManagerBean 
DefinitionParser()); 
} 
根据 自 定 义 标签 的 使 用 规则 以 及 上 面 的 代码 ， 可 以 知道 ， 在 遇 到 
诸如 <tx:annotation-driven 为 开头 的 配置 后 ，Spring 都 会 使 用 
AnnotationDrivenBeanDefinitionParser 类 的 parse 方 法 进行 解析 。 
public BeanDefinition parse(Element element, ParserContext 
parserContext) { 
String mode = element.getAttribute("mode"); 
if ("aspectj".equals(mode)) { 
// mode-"aspectj" 
registerTransactionAspect(element, parserContext); 
jelse { 


/ mode="proxy" 
AopAutoProxyConfigurer.configureAutoProxyCreator(element, 
parserContext); 
} 
return null; 

} 

在 解析 中 存在 对 于 mode 属性 的 判断 ， 根 据 代 码 ， 如 果 我 们 需 
使 用 Aspect) 的 方式 进行 事务 切入 《Spring 中 的 事务 是 以 AOP 为 基础 
AY) ， 那 么 可 以 使 用 这 样 的 配置 : 

«tx:annotation-driven transaction-manager="transactionManager" 


mode="aspectj" /> 


10.2.1 注册 InfrastructureAdvisorAutoProxyCreator 
我 们 以 默认 配置 为 例子 进行 分 析 ， 进 入 AopAutoProxyConfigurer 类 


的 configureAutoProxyCreator: 
public static void configureAutoProxyCreator(Element element, 


ParserContext parserContext) { 


AopNamespaceUtils.registerAutoProxyCreatorIf Necessary(parserContext, 
element); 
//TRANSACTION ADVISOR. BEAN NAME 
="org.Springframework.transaction.config.internal 
TransactionAdvisor"; 
String txAdvisorBeanName = 
TransactionManagementConfigUtils. TRANSACTION _ 
ADVISOR_BEAN_NAME; 


if (!parserContext.getRegistry().containsBeanDefinition 
(txAdvisorBean Name)) 1 
Object eleSource = parserContext.extractSource(element); 
/创建 TransactionAttributeSource 的 bean 
RootBeanDefinition sourceDef = new RootBeanDefinition 
(Annotation 
TransactionAttributeSource.class); 


sourceDef.setSource(eleSource); 


sourceDef.setRole(BeanDefinition.ROLE INFRASTRUCTURE); 
/注册 bean, 并 使 用 Spring 中 的 定义 规则 生成 beanname 
String sourceName = parserContext.getReaderContext(). 
registerWithGeneratedName 
(sourceDef); 
/创建 TransactionInterceptor 的 bean 
RootBeanDefinition interceptorDef = new RootBeanDefinition 
(TransactionInterceptor.class); 


interceptorDef.setSource(eleSource); 


interceptorDef.setRole(BeanDefinition.ROLE INFRASTRUCTURE); 


register TransactionManager(element, interceptorDef); 


interceptorDef.getProperty Values().add("transactionAttributeSource", 
new RuntimeBeanReference(sourceName)); 
/注册 bean, 并 使 用 Spring 中 的 定义 规则 生成 beanname 
String interceptorName = parserContext.getReaderContext(). 


Register 


WithGeneratedName(interceptorDef); 

/创建 TransactionAttributeSourceAdvisor 的 bean 

RootBeanDefinition advisorDef = new RootBeanDefinition 
(BeanFactory 

TransactionAttributeSourceA dvisor.class); 


advisorDef.setSource(eleSource); 


advisorDef.setRole(BeanDefinition.ROLE INFRASTRUCTURE); 
// 将 sourceName 的 bean 注 入 advisorDef 的 
transactionAttributeSource 属 性 中 


advisorDef.getProperty Values().add("transactionAttributeSource", 
new RuntimeBeanReference(sourceName)); 
/将 interceptorName 的 bean 注 入 advisorDef 的 adviceBeanName 属 
性 中 
advisorDef.getProperty Values().add(" adviceBeanName", 
interceptorName); 
/如 果 配 置 了 order 属 性 ， 则 加 入 到 bean 中 
if (element.hasAttribute("order")) 1 
advisorDef.getProperty Values().add( "order", 
element.getAttribute 
("order"); 


parserContext.getRegistry().registerBeanDefinition(txAdvisorBeanName, 
advisorDef); 


/创建 CompositeComponentDefinition 


CompositeComponentDefinition compositeDef = new 
CompositeComponent 
Definition(element.getTagName(), eleSource); 
compositeDef.addNestedComponent(new 
BeanComponentDefinition (sourceDef, 
sourceName)); 
compositeDef.addNestedComponent(new 
BeanComponentDefinition(interceptorDef, 
interceptorName)); 
compositeDef.addNestedComponent(new 
BeanComponentDefinition(advisorDef, 
txAdvisorBeanName)); 


parserContext.registerComponent(compositeDef); 


} 

上 面 的 代码 注册 了 代理 类 及 三 个 bean， 很 多 恋 者 会 直接 略 过 ， 认 
为 只 是 注册 三 个 bean 而 已 ， 确 实 ， 这 里 只 注册 了 三 个 bean， 但 是 这 三 
个 bean 支 撑 了 整个 的 事务 功能 ， 那 么 这 三 个 bean 是 怎么 组 织 起 来 的 
呢 ? 

首先 ， 其 中 的 两 个 bean 被 注册 到 了 一 个 名 为 advisorDef 的 bean 
中 ，advisorDef 使 用 BeanFactoryTransactionAttributeSourceAdvisor 作为 
其 class 属性 。 也 就 是 说 BeanFactoryTransaction AttributeSourceAdvisor 
代表 着 当前 bean， 如 图 10-1 所 示 ， 有 具体 代码 如 下 : 

advisorDef.getProperty Values().add(" adviceBeanName", 


interceptorName); 


BeanFactoryTransactionAttributeSourceAdvisor 
AnnotationTransactionAttributeSource Trans actienintercepter 
LE | 
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那么 如 此 组 装 的 目的 是 什么 呢 ? 我 们 暂且 留 下 一 个 悬念 ， 接 着 分 
析 代 码 。 上 面 疯 数 configureAutoProxyCreator 中 的 第 一 句 貌 似 很 简单 但 
却 是 很 重要 的 代码 : 
AopNamespaceUtils.registerAutoProxyCreatorIfNecessary(parserCont 
ext, element); 
Xt Ni PRR: 
public static void registerAutoProxyCreatorIf Necessary( 
ParserContext parserContext, Element sourceElement) 1 
BeanDefinition beanDefinition = 
AopConfigUtils.registerAutoProxyCreatorlf 
Necessary( 
parserContext.getRegistry(), parserContext.extractSource (source 
Element)); 
useClassProxyingIfNecessary(parserContext.getRegistry(), 
sourceElement); 


registerComponentIfNecessary(beanDefinition, parserContext); 


public static BeanDefinition 
registerAutoProxyCreatorIfNecessary(BeanDefinitionRegistry 
registry, Object Source) { 
return 
registerOrEscalateApcAsRequired(InfrastructureA dvisorAutoProxyCreator. 
class, registry, source); 


} 

对 于 解析 来 的 代码 流程 AOP 中 已 经 有 所 分 析 ， 上 面 的 两 个 水 数 主 
要 目的 是 注册 了 InfrastructureAdvisorAutoProxyCreator 类 型 的 bean， 那 
么 注册 这 个 类 的 目的 是 什么 呢 ? 查看 这 个 类 的 层次 ， 如 图 10-2 所 示 。 


F K9 InfrastructureAdvisorAutoProxyCreator 
4 (9^ AbstractAdvisorAutoProxyCreator 
4 (9^ AbstractAutoProxyCreator 
4 (9 ProxyConfig 
(9 Object 
© Serializable 
@ AoplnfrastructureBean 
Q BeanClassLoaderAware 
Q Aware 
4 © BeanFactoryAware 
Q Aware 
@ Ordered 
Q SmartinstantiationAwareB eanPostProcessor 
4 


Q InstantiationAwareB eanPostProcessor 


四 BeanPostProcessor 


图 10-2 InfrastructureAdvisorAutoProxyCreator 类 的 层次 结构 图 


从 上 面 的 层次 结构 中 可 以 看 到 ， 
InfrastructureAdvisorAutoProxyCreator 间 ] 接 实现 了 


SmartInstantiationAwareBeanPostProcessor, [fl] 


SmartInstantiationAwareBeanPostProcessor 又 继承 自 
InstantiationAwareBeanPostProcessor， 也 就 是 说 在 Spring 中 ， 所 有 bean 
实例 化 时 Spring 都 会 保证 调用 其 postProcessAfterInitialization 方 法 ， 其 
实现 是 在 父 类 AbstractAutoProxyCreator 类 中 实现 。 
以 之 前 的 示例 为 例 ， 当 实例 化 userService 的 bean 时 便 会 调用 此 方 
法 ， 方 法 如 下 : 
public Object postProcessAfterInitialization(Object bean, String 
beanName) throws 
BeansException 1 
if (bean != null) { 
/根据 给 定 的 bean 的 class 和 name 构 建 出 个 key， 
beanClassName beanName 
Object cacheKey = getCacheKey(bean.getClass(), beanName); 
/是 否 是 由 于 避免 循环 依赖 而 创建 的 bean 代 理 
if (!this.earlyProxyReferences.contains(cacheKey)) { 


return wrapIfNecessary(bean, beanName, cacheKey); 


} 
return bean; 
} 
这 里 实现 的 主要 目的 是 对 指定 bean 进行 封装 ， 当 然 首先 要 确定 是 
否 需要 封装 ， 检 测 及 封装 的 工作 都 委托 给 了 wrapIfNecessary 图 数 进 
行 。 
protected Object wrapIfNecessary(Object bean, String beanName, 
Object cacheKey) 1 
/如 果 已 经 处 理 过 


if (this.targetSourcedBeans.contains(beanName)) { 


return bean; 
j 
if (this.nonAdvisedBeans.contains(cacheKey)) 1 
return bean; 
j 
/给 定 的 bean 类 是 否 代表 一 个 基础 设施 类 ， 不 应 代理 ,或 者 配置 
了 指定 bean 不 需要 自动 代理 
if (isInfrastructureClass(bean.getClass()) || 
shouldSkip(bean.getClass(), 
beanName)) 1 
this.nonAdvisedBeans.add(cacheKey); 
return bean; 
j 
// Create proxy if we have advice. 
Object[] specificInterceptors = 
getAdvicesAndAdvisorsForBean(bean.getClass(), 
beanName, null); 
if (specificInterceptors '- DO NOT PROXY) ( 
this.advisedBeans.add(cacheKey); 
Object proxy = createProxy(bean.getClass(), beanName, 
specificInterceptors, 
new SingletonTargetSource(bean)); 
this.proxy Types.put(cacheKey, proxy.getClass()); 
return proxy; 
j 
this.nonAdvisedBeans.add(cacheKey); 


return bean; 


} 

wrapIfNecessary 国 数 功能 实现 起 来 很 复杂 ， 但 是 逻辑 上 理解 起 来 
还 是 相对 简单 的 ， 在 wrapIfNecessary 国 数 中 主要 的 工作 如 下 。 

(1) 找 出 指定 bean 对 应 的 增强 器 。 

(2) 根据 找 出 的 增强 器 创建 代理 。 

听 直 来 似乎 简单 的 逻辑 ，Spring 中 又 做 了 哪些 复杂 的 工作 呢 ? 对 
于 创建 代理 的 部 分 ， 通 过 之 前 的 分 析 相 信 大 家 已 经 很 熟悉 了 ， 但 是 对 
于 增强 器 的 获取 ，Spring 又 是 怎么 做 的 呢 ? 


10.2.2 获取 对 应 class/method 的 增强 器 


获取 指定 bean 对 应 的 增强 器 ， 其 中 包含 两 个 关键 字 : 增强 器 与 对 
立 。 也 就 是 说 在 getAdvicesAndAdvisorsForBean Kh, MERR HiH 
强 器 ， 而 且 还 需要 判断 增强 器 是 否 满足 要 求 。 
protected Object[] getAdvicesAndAdvisorsForBean(Class beanClass, 
String beanName, 
TargetSource targetSource) { 
List advisors = findEligibleAdvisors(beanClass, beanName); 
if (advisors.isEmpty()) { 
return DO NOT PROXY; 
j 
return advisors.toArray(); 
} 
protected List<Advisor> findEligibleAdvisors(Class beanClass, String 
beanName) { 
List<Advisor> candidateAdvisors = findCandidateAdvisors(); 
List<Advisor> eligibleAdvisors = 


findAdvisorsThatCanApply(candidateA dvisors, 


beanClass, beanName); 
extendA dvisors(eligibleAdvisors); 
if (leligibleAdvisors.isEmpty()) 1 
eligibleAdvisors = sortAdvisors(eligibleAdvisors); 
l; 
return eligibleAdvisors; 
j 
其 实 我 们 也 渐渐 地 体会 到 了 Spring 中 代码 的 优秀 ， 即 使 是 一 个 很 
复杂 的 逻辑 ， 在 Spring 中 也 会 被 拆 分 成 若干 个 小 的 逻辑 ， 然 后 在 每 个 
国 数 中 实现 ， 使 得 每 个 国 数 的 逻辑 简单 到 我 们 能 快速 地 理解 ， 而 不 会 
像 有 些 人 开发 的 那样 ， 将 一 大 堆 的 逻辑 都 罗列 在 一 个 函数 中 ， 给 后 期 
维护 人 员 造 成 巨大 的 困扰 。 
同样 ， 通 过 上 面 的 函数 ，Spring 又 将 任务 进行 了 拆 分 ， 分 成 了 获 
取 所 有 增强 器 与 增强 器 是 否 匹 配 两 个 功能 点 。 
1. 寻找 候选 增强 器 
在 findCandidateAdvisors 函 数 中 完成 的 就 是 获取 增强 器 的 功能 。 
protected List<Advisor> findCandidateAdvisors() 1 
return this.advisorRetrievalHelper.findAdvisorBeans(); 
j 
public List<Advisor> findAdvisorBeans() { 
// Determine list of advisor bean names, if not cached already. 
String[] advisorNames - null; 
synchronized (this) 1 
advisorNames - this.cachedAdvisorBeanNames; 
if (advisorNames == null) 1 
advisorNames = 


BeanFactoryUtils.beanNamesForTypeIncludingAncestors( 


this.beanFactory, Advisor.class, true, false); 


this.cachedAdvisorBeanNames - advisorNames; 


j 
if (advisorNames.length == 0) { 
return new LinkedList<Advisor>(); 
i 
List<Advisor> advisors = new LinkedList<Advisor>(); 
for (String name : advisorNames) { 
if (isEligibleBean(name) && 
!this.beanFactory.isCurrentlyInCreation(name)) 1 
try { 
advisors.add(this.beanFactory.getBean(name, 
Advisor.class)); 
} 
catch (BeanCreationException ex) { 
Throwable rootCause = ex.getMostSpecificCause(); 
if (rootCause instanceof 
BeanCurrentlyInCreationException) { 
BeanCreationException bce = (BeanCreationException) 
rootCause; 
if 
(this.beanFactory.isCurrentlyInCreation(bce.getBeanName())) { 
if (logger.isDebugEnabled()) { 
logger.debug("Ignoring currently created advisor "' 


+ name + "': "+ ex.getMessage()); 


continue; 


} 


throw ex; 


j 
return advisors; 

j 

对 于 上 面 的 函数 ， 你 看 懂 其 中 的 奥妙 了 吗 ? 首 先是 通过 
BeanFactoryUtils 类 提供 的 工具 方法 获取 所 有 对 应 Advisorclass 的 类 ， 
获取 办 法 无 非 是 使 用 ListableBeanFactory 中 提供 的 方法 : 

String[] getBeanNamesForType(Class<?> type, boolean 
includeNonSingletons, boolean 

allowEagerlnit); 

而 当 我 们 知道 增强 器 在 容器 中 的 beanName 时 ， 获 取 增 强 器 已 经 不 
是 问题 了 ， 在 BeanFactory 中 提供 了 这 样 的 方法 ， 可 以 帮助 我 们 快速 定 
位 对 应 的 bean 实 例 。 

«T» T getBean(String name, Class<T> requiredType) throws 
BeansException; 

或 许 你 已 经 所 了 之 前 留 下 的 悬念 ， 在 我 们 讲解 自 定 义 标签 时 曾经 
注册 了 一 个 类 型 为 BeanFactoryTransactionAttributeSourceAdvisor 的 
bean， 而 在 此 bean 中 我 们 又 注入 了 另外 两 个 Bean， 那 么 此 时 这 个 
Bean 就 会 被 开始 使 用 了 。 因 为 BeanFactoryTransactionAttribute Source 
Advisor 同 样 也 实现 了 Advisor 接 口 ， 那 么 在 获取 所 有 增强 器 时 自然 也 会 
将 此 bean 提 取出 来 ， 并 随 着 其 他 增强 器 一 起 在 后 续 的 步骤 中 被 织 入 代 
理 。 


2. 候选 增强 器 中 寻找 到 匹配 项 
当 找 出 对 应 的 增强 器 后 ， 接 来 的 任务 就 是 看 这 些 增强 器 是 否 与 对 
应 的 class 匹配 了 ， 当 然 不 只 是 class，class 内 部 的 方法 如 果 匹 配 也 可 以 
通过 验证 。 
public static List<Advisor> 
findAdvisorsThatCanApply(List<Advisor> candidateAdvisors, 
Class<?> clazz) { 
if (candidateA dvisors.isEmpty()) 1 
return candidateAdvisors; 
j 
List<Advisor> eligibleAdvisors = new LinkedList<Advisor>(); 
/首先 处 理 引 介 增 强 
for (Advisor candidate : candidateAdvisors) { 
if (candidate instanceof IntroductionAdvisor && 
canApply(candidate, clazz)) 1 
eligibleAdvisors.add(candidate); 


j 
boolean hasIntroductions = !eligibleAdvisors.isEmpty(); 
for (Advisor candidate : candidateAdvisors) { 
// 引 介 增 强 已 经 处 理 
if (candidate instanceof IntroductionAdvisor) { 
continue; 
} 
// 对 于 普通 bean 的 处 理 
if (canApply(candidate, clazz, hasIntroductions)) { 
eligibleAdvisors.add(candidate); 


j 
return eligibleAdvisors; 
j 
public static boolean canApply(Advisor advisor, Class<?> targetClass, 
boolean 
hasIntroductions) 1 
if (advisor instanceof IntroductionAdvisor) 1 
return((IntroductionAdvisor)advisor).getClassFilter().Matches 
(targetClass); 
}else if (advisor instanceof PointcutAdvisor) { 
PointcutAdvisor pca = (PointcutAdvisor) advisor; 
return canApply(pca.getPointcut(), targetClass, 
hasIntroductions); 
jelse { 


return true; 


} 
当前 我 们 分 析 的 是 对 于 UserService 是 否 适 用 于 此 增强 方法 ， 那 么 
当前 的 advisor 就 是 之 前 查 —- 
BeanFactoryTransactionAttributeSourceAdvisor 的 bean 实 例 ， 而 通过 类 的 
层次 结构 我 们 又 知道 : BeanFactoryTransactionAttributeSourceAdvisor 
间接 实现 了 PointcutAdvisor。 因 此 ， 在 canApply 函数 中 的 第 二 个 庄 判 
断 时 就 会 通过 判断 ， 会 将 BeanFactory Transaction 
AttributeSourceAdvisor 中 的 getPointcut() 方 法 返回 值 作为 参数 继续 调用 
canApply 方法 ， 而 getPoint() 方 法 返回 的 是 
TransactionAttributeSourcePointcut 类 型 的 实例 。 对 于 


transactionAttribute Source 这 个 属性 大 家 还 有 印象 吗 ? 这 是 在 解析 自 定 
义 标签 时 注入 进去 的 。 
private final TransactionAttributeSourcePointcut pointcut = new 
TransactionAttribute 
SourcePointcut() { 
@Override 
protected TransactionAttributeSource 
getTransactionAttributeSource() { 
return transactionAttributeSource; 
} 
H 
那么 ， 使 用 ransactionAttributeSourcePointcut 类 型 的 实例 作为 水 数 
参数 继续 跟踪 canApply。 
public static boolean canApply(Pointcut pc, Class<?> targetClass, 
boolean hasIntroductions) { 
Assert.notNull(pc, "Pointcut must not be null"); 
if (!*pc.getClassFilter().matches(targetClass)) 1 
return false; 
j 
// 此 时 的 pc 表示 TransactionAttributeSourcePointcut 
//pc.getMethodMatcher() 返 回 的 正 是 自身 (this). 
MethodMatcher methodMatcher = pc.getMethodMatcher(); 
IntroductionAwareMethodMatcher 
introductionAwareMethodMatcher = null; 
if (methodMatcher instanceof IntroductionAwareMethodMatcher) 1 
introductionAwareMethodMatcher = 


(IntroductionAwareMethodMatcher) methodMatcher; 


j 
Set<Class> classes = new HashSet<Class>(ClassUtils. 
GetAllInterfaces 
ForClassAsSet(targetClass)); 
classes.add(targetClass); 
//classes:[interface test.ITTestBean, class test. TestBean | 
for (Class<?> clazz : classes) { 
Method[] methods = clazz.getMethods(); 
for (Method method : methods) { 
if ((introductionAwareMethodMatcher != null && 
introductionAwareMethodMatcher.matches(method, 
targetClass, 
hasIntroductions)) || 
methodMatcher.matches(method, targetClass)) { 


return true; 


} 
return false; 
} 
通过 上 面 阔 数 大 致 可 以 理 清 大 体 脉 络 ， 首 先 获取 对 应 类 的 所 有 接 
口 并 连同 类 本 身 一 起 遍历， 遍历 过 程 中 又 对 类 中 的 方法 再 次 人 遍历， 一 
旦 匹配 成 功 便 认为 这 个 类 适用 于 当前 增强 器 。 
到 这 里 我 们 不 禁 会 有 疑问 ， 对 于 事物 的 配置 不 仅仅 局 限于 在 阔 数 
上 配置 ， 我 们 都 知道 ， 在 类 活 接口 上 的 配置 可 以 延续 到 类 中 的 每 个 孙 
数 ， 那 么 ， 如 果 针 对 每 个 函数 进行 检测 ， 在 类 本 身上 配置 的 事务 属性 
吉 不 是 检测 不 到 了 吗 ? 带 着 这 个 疑问 ， 我 们 继续 探求 matcher 方 法 。 


做 匹配 的 时 候 methodMatcher.matches(method, targetClass) 会 使 用 
TransactionAttributeSource Pointcut 类 的 matches 方 法 。 

public boolean matches(Method method, Class targetClass) { 

// 自 定义 标签 解析 时 注入 

TransactionAttributeSource tas = getTransactionAttributeSource(); 

return (tas == null || tas.getTransactionAttribute(method, 
targetClass) != null); 

} 

此 时 的 tas 表 示 AnnotationTransactionAttributeSource 类 型 ， 而 
AnnotationTransactionAttribute Source 类 型 的 getTransactionAttribute 方 法 
如 下 : 

public TransactionAttribute getTransactionAttribute(Method method, 
Class<?> 

targetClass) { 

Object cacheKey = getCacheKey(method, targetClass); 
Object cached = this.attributeCache.get(cacheKey); 
if (cached != null) { 
if (cached == NULL_TRANSACTION_ATTRIBUTE) { 
return null; 
j 
else { 


return (TransactionAttribute) cached; 


j 
else { 
TransactionAttribute tx Att = 


computeTransactionAttribute(method, targetClass); 


// Put it in the cache. 
if (txAtt == null) { 
this.attributeCache.put(cacheKey, 
NULL TRANSACTION ATTRIBUTE); 


j 
else { 
if (logger.isDebugEnabled()) { 
logger.debug(" Adding transactional method "+ 
method.getName() 
+ ™ with attribute: " + txAtt); 
j 
this.attributeCache.put(cacheKey, txAtt); 
j 
return txAtt; 


j 

很 遗憾 ， 在 getTransactionAttribute 国 数 中 并 没有 找到 我 们 想 要 的 代 
码 ， 这 里 是 指 常规 的 一 贯 的 套路 。 尝 试 从 缓存 加 载 ， 如 果 对 应 信息 没 
有 被 缓存 的 话 ， 工 作 又 委托 给 了 computeTransaction AttributeEK|Zk, {E 
computeTransactionAttribute 汶 数 中 终于 的 我 们 看 到 了 事务 标签 的 提取 
过 程 。 

3. 提取 事务 标签 

private TransactionAttribute computeTransactionAttribute(Method 
method, Class<?> 

targetClass) { 


// Don't allow no-public methods as required. 


if (allowPublicMethodsOnly() && 
!Modifier.isPublic(method.getModifiers())) { 
return null; 
} 
// Ignore CGLIB subclasses - introspect the actual user class. 
Class<?> userClass = ClassUtils.getUserClass(targetClass); 
/method 代 表 接 口中 的 方法 ，specificMethod 代 表 实 现 类 中 的 方 
法 
Method specificMethod = 
ClassUtils.get MostSpecificMethod(method, userClass); 
// If we are dealing with method with generic parameters, find the 
original method. 
specificMethod - 
BridgeMethodResolver.findBridgedMethod(specificMethod); 
// 查 看 方法 中 是 否 存在 事务 声明 
TransactionAttribute txAtt = 
findTransactionAttribute(specificMethod); 
if (txAtt != null) { 


return txAtt; 


} 
/查看 方法 所 在 类 中 是 否 存在 事务 声明 
txAtt = 


findTransactionAttribute(specificMethod.getDeclaringClass()); 
if (txAtt != null) { 
return txAtt; 
} 
/如 果 存 在 接口 ， 则 到 接口 中 去 寻找 


if (specificMethod != method) { 
// 查 找 接口 方法 
txAtt = findTransactionAttribute(method); 
if (txAtt != null) { 
return txAtt; 
} 
// 到 接口 中 的 类 中 去 寻找 
return findTransactionAttribute(method.getDeclaringClass()); 
} 
return null; 
} 
对 于 事务 属性 的 获取 规则 相信 大 家 都 已 经 很 清楚 ， 如 果 方 法 中 存 
在 事务 属性 ， 则 使 用 方法 上 的 属性 ， 否 则 使 用 方法 所 在 的 类 上 的 属 
性 ， 如 果 方 法 所 在 类 的 属性 上 还 是 没有 搜寻 到 对 应 的 事务 属性 ， 那 么 
再 搜寻 接口 中 的 方法 ， 再 没有 的 话 ， 最 后 尝试 搜寻 接口 的 类 上 面 的 声 
明 。 对 于 函数 computeTransactionAttribute 中 的 逻辑 与 我 们 所 认识 的 规 
则 并 无 差别 ， 但 是 上 面 阔 数 中 并 没有 真正 的 去 做 搜寻 事务 属性 的 逻 
辑 ， 而 是 搭建 了 个 执行 框架 ， 将 搜寻 事务 属性 的 任务 委托 给 了 
findTransactionAttribute 方 法 去 执行 。 
protected TransactionAttribute findTransactionAttribute(Method 
method) { 
return determineTransactionAttribute(method); 
j 
protected TransactionAttribute 
determineTransactionAttribute( AnnotatedElement ae) 1 
for (TransactionAnnotationParser annotationParser : 


this.annotationParsers) { 


TransactionAttribute attr = annotationParser.parseTransaction 
Annotation (ae); 
if (attr != null) { 


return attr; 


} 
return null; 
} 
this.annotationParsers 是 在 当前 类 
AnnotationTransactionAttributeSource 初 始 化 的 时 候 初始 化 的 ， 其 中 的 
值 被 加 入 了 SpringTransactionAnnotationParser， 也 就 是 当 进 行 属性 获取 
的 时 候 其 实 是 使 用 SpringTransactionAnnotationParser 类 的 
parseTransactionAnnotation 方法 进行 解析 的 。 
public TransactionAttribute 
parseTransactionAnnotation( AnnotatedElement ae) 1 
Transactional ann = AnnotationUtils.getAnnotation(ae, 
Transactional.class); 
if (ann != null) { 
return parseTransactionAnnotation(ann); 
j 
else { 


return null; 


} 
至 此 ， 我 们 终于 看 到 了 想 看 到 的 获取 注解 标记 的 人 代码。 首先 会 判 
断 当 前 的 类 是 否 含 有 Transactional 注解 ， 这 是 事务 属性 的 基础 ， 当 然 


如 果 有 的 话 会 继续 调用 parseTransactionAnnotation 方 法 解析 详细 的 属 
性 。 
public TransactionAttribute parseTransactionAnnotation(Transactional 

ann) { 

RuleBasedTransactionAttribute rbta = new 
RuleBasedTransactionAttribute(); 

/解析 propagation 

rbta.setPropagationBehavior(ann.propagation().value()); 

/解析 isolation 

rbta.setIsolationLevel(ann.isolation().value()); 

/解析 timeonut 

rbta.setTimeout(ann.timeout()); 

/解析 readOnly 

rbta.setReadOnly(ann.readOnly()); 

/解析 value 

rbta.setQualifier(ann.value()); 

ArrayList<RollbackRuleAttribute> rollBackRules = new 
ArrayList<RollbackRule 

Attribute>(); 

/解析 rollbackFor 

Class[] rbf = ann.rollbackFor(); 

for (Class rbRule : rbf) { 

RollbackRuleAttribute rule = new 
RollbackRuleAttribute(rbRule); 
rollBackRules.add(rule); 
j 
/解析 rollbackForClassName 


String[] rbfc = ann.rollbackForClassName(); 
for (String rbRule : rbfc) 1 
RollbackRuleAttribute rule = new 
RollbackRuleAttribute(rbRule); 
rollBackRules.add(rule); 
} 
/解析 noRollbackFor 
Class[] nrbf = ann.noRollbackFor(); 
for (Class rbRule : nrbf) { 
NoRollbackRuleAttribute rule = new 
NoRollbackRuleAttribute(rbRule); 
rollBackRules.add(rule); 
j 
/解析 noRollbackForClassName 
String[] nrbfc = ann.noRollbackForClassName(); 
for (String rbRule : nrbfc) { 
NoRollbackRuleAttribute rule = new 
NoRollbackRuleAttribute(rbRule); 
rollBackRules.add(rule); 
j 
rbta.getRollbackRules().addAll(rollBackRules); 
return rbta; 
j 
上 面 方法 中 实现 了 对 对 应 类 或 者 方法 的 事务 属性 解析 ， 你 会 在 这 
个 类 中 看 到 任何 你 党 用 或 者 不 常用 的 属性 提取 。 
至 此 ， 我 们 终于 完成 了 事务 标签 的 解析 。 我 们 是 不 是 分 析 的 太 远 
了 ， 似 乎 已 经 所 了 从 哪里 开始 了 。 再 回顾 一 下 ， 我 们 的 现在 的 任务 是 


找 出 某 个 增强 器 是 否 适合 于 对 应 的 类 ， 而 是 否 匹 配 的 关键 则 在 于 是 否 
从 指定 的 类 或 类 中 的 方法 中 找到 对 应 的 事务 属性 ， 现 在 ， 我 们 以 
UserServiceImpl 为 例 ， 已 经 在 它 的 接口 UserService 中 找到 了 事务 属 
性 ， 所 以 ， 它 是 与 事务 增强 器 匹配 的 ， 也 就 是 它 会 被 事务 功能 修饰 。 
至 此 ， 事 务 功能 的 初始 化 工作 便 结束 了 ， 当 判断 某 个 bean 适用 于 
事务 增强 时 ， 也 就 是 适用 于 增强 器 
BeanFactory TransactionAttributeSourceAdvisor, *2#8, XRAgX« T 25, PH 
以 说 ， 在 自 定 义 标签 解析 时 ， 注 入 的 类 成 为 了 整个 事务 功能 的 基础 。 
BeanFactoryTransactionAttributeSourceAdvisor 作 为 Advisor 的 实现 
类 ， 上 自然 要 遵从 Advisor 的 处 理 方式 ， 当 代理 被 调用 时 会 调用 这 个 类 的 
增强 方法 ， 也 就 是 此 bean 的 Advise， 又 因为 在 解析 事务 定义 标签 时 我 
们 把 TransactionInterceptor 类 型 的 bean 注入 到 了 BeanFactory 
TransactionAttributeSourceAdvisor 中 ， 所 以 ， 在 调用 事务 增强 器 增强 
的 代理 类 时 会 首先 执行 TransactionInterceptor 进 行 增强 ， 同 时 ， 也 就 是 
在 TransactionInterceptor 类 中 的 invoke 方 法 中 完成 了 整个 事务 的 逻辑 。 


10.3 事务 增强 器 


TransactionInterceptor 支撑 着 整个 事务 功能 的 架构 ， 逻 辑 还 是 相对 
复杂 的 ， 那 么 现在 我 们 切入 正题 来 分 析 此 拦截 器 是 如 何 实现 事务 特性 
的 。TransactionInterceptor 类 继承 自 MethodInterceptor， 所 以 调用 该 类 
是 从 其 invoke 方 法 开始 的 ， 首 先 预 此 下 这 个 方法 : 

public Object invoke(final MethodInvocation invocation) throws 
Throwable 1 

Class<?> targetClass = (invocation.getThis() != null ? 
AopUtils.getTargetClass 
(invocation.getThis()) : null); 


/获取 对 应 事务 属性 
final TransactionAttribute txAttr = 
getTransactionAttributeSource().getTransactionAttribute 
(invocation. 
getMethod(), targetClass); 
/获取 beanFactory 中 的 transactionManager 
final PlatformTransactionManager tm = 
determineTransactionManager(txAttr); 
/构造 方法 唯一 标识 (类 .方法 ， 如 service.UserServiceImpl.save) 
final String joinpointIdentification = methodIdentification (invocation. 
getMethod(), targetClass); 
/声明 式 事 务 处 理 
if (txAttr == null || !(tm instanceof 
CallbackPreferringPlatformTransaction 
Manager)) { 
/创建 TransactionInfo 
TransactionInfo txInfo = createTransactionIfNecessary(tm, 
txAttr, joinpoint 
Identification); 
Object retVal = null; 
try { 
/执行 被 增强 方法 
retVal = invocation.proceed(); 
j 
catch (Throwable ex) 1 
/ 异 单 回 滚 


completeTransactionAfterThrowing(txInfo, ex); 


throw ex; 
j 
finally { 
/清除 信息 
cleanupTransactionInfo(txInfo); 
} 
// 提 交 事 务 
commitTransactionA fterReturning(txInfo); 
return ret Val; 
} 
else { 
// 编 程式 事务 处 理 
try { 
Object result = 
((CallbackPreferringPlatformTransactionManager) tm). 
execute(txA ttr, 
new TransactionCallback<Object>() 1 
public Object doInTransaction(TransactionStatus status) { 
TransactionInfo txInfo = prepareTransactionInfo(tm, 
txAttr, joinpointIdentification, status); 
try { 
return invocation.proceed(); 
j 
catch (Throwable ex) 1 
if (txAttr.rollbackOn(ex)) 1 
// A RuntimeException: will lead to a rollback. 


if (ex instanceof RuntimeException) { 


throw (RuntimeException) ex; 
} 
else { 
throw new ThrowableHolderException(ex); 


} 


else { 
// A normal return value: will lead to a commit. 


return new ThrowableHolder(ex); 


} 
finally { 


cleanupTransactionInfo(txInfo); 


} 
D; 


// Check result: It might indicate a Throwable to rethrow. 
if (result instanceof ThrowableHolder) { 
throw ((ThrowableHolder) result).getThrowable(); 
} 
else { 


return result: 


} 
catch (ThrowableHolderException ex) { 


throw ex.getCause(); 


} 

从 上 面 的 函数 中 ， 我 们 演 试 整理 下 事务 处 理 的 脉络 ， 在 Spring 中 
支持 两 种 事务 处 理 的 方式 ， 分 别 是 声明 式 事务 处 理 与 编程 式 事务 处 
理 ， 两 者 相对 于 开发 人 员 来 讲 差别 很 大 ， 但 是 对 于 Spring 中 的 实现 来 
讲 ， 大 同 小 异 。 在 invoke 中 我 们 也 可 以 看 到 这 两 种 方式 的 实现 。 考 虑 
到 对 事务 的 应 用 比 声 明 式 的 事务 处 理 使 用 起 来 方便 ， 也 相对 流行 些 ， 
我 们 就 以 此 种 方式 进行 分 析 。 对 于 声明 式 的 事务 处 理 主要 有 以 下 几 个 
步骤 。 

(1) 获取 事务 的 属性 。 

对 于 事务 处 理 来 说 ， 最 基础 或 者 说 最 首要 的 工作 便 是 获取 事务 属 
性 了 ， 这 是 支撑 整个 事务 功能 的 基石 ， 如 果 没 有 事务 属性 ， 其 他 功能 
也 无 从 谈 起 ， 在 分 析 事 务 准备 阶段 时 我 们 已 经 分 析 了 事务 属性 提取 的 
功能 ， 大 家 应 该 有 所 了 解 。 

(2) 加 载 配 置 中 配置 的 TransactionManager。 
(3) 不 同 的 事务 处 理 方式 使 用 不 同 的 逻辑 。 

对 于 声明 式 事 务 的 处 理 与 编程 式 事务 的 处 理 ， 第 一 点 区 别 在 于 事 
务 属性 上 ， 因 为 编程 式 的 事务 处 理 是 不 需要 有 事务 属性 的 ， 第 二 点 区 
别 就 是 在 TransactionManager 上 ，CallbackPreferring 
PlatformTransactionManager 实现 PlatformTransactionManager 接口 ， 暴 
露出 一 个 方法 用 于 执行 事务 处 理 中 的 回调 。 所 以 ， 这 两 种 方式 都 可 以 
用 作 事 务 处 理 方 式 的 判断 。 

(4) 在 目标 方法 执行 前 获取 事务 并 收集 事务 信息 。 
事务 信息 与 事务 属性 并 不 相同 ， 也 就 是 TransactionInfo 与 
TransactionAttribute 并 不 相同 ， TransactionInfo 中 包含 
TransactionAttribute 信 息 ， 但 是 ， 除 了 TransactionAttribute 外 还 有 其 他 


事务 信息 ， 例 如 PlatformTransactionManager 以 及 TransactionStatus 相 关 
信息 。 

(5) 执行 目标 方法 。 

(6) 一 旦 出 现 异常 ， 尝 试 异常 处 理 。 

并 不 是 所 有 异常 ，Spring 都 会 将 其 回 滚 ， 默 认 只 对 
RuntimeException 回 滚 。 

(7) 提交 事务 前 的 事务 信息 清除 。 

(8) 提交 事务 。 

上 面 的 步骤 分 析 旨 在 让 大 家 对 事务 功能 与 步骤 有 个 大 致 的 了 解 ， 
具体 的 功能 还 需要 详细 地 分 析 。 


10.3.1 创建 事务 
我 们 先 分 析 事 务 创建 的 过 程 。 


protected TransactionInfo createTransactionIfNecessary( 
PlatformTransactionManager tm, TransactionAttribute txAttr, final 
String 
joinpointIdentification) { 
// If no name specified, apply method identification as transaction 
name. 
/如 果 疫 有 名 称 指定 则 使 用 万 法 唯一 标识 ， 并 使 用 
DelegatingTransactionAttribute£}3etx Attr 
if (txAttr != null && txAttr.getName() == null) { 
txAttr = new DelegatingTransactionAttribute(txAttr) { 
@Override 
public String getName() { 


return joinpointIdentification; 


H 
j 
TransactionStatus status = null; 
if (txAttr != null) 1 
if (tm != null) { 
/获取 TransactionStatus 
status = tm.get Transaction(txA ttr); 
j 
else { 
if (logger.isDebugEnabled()) 1 
logger.debug("Skipping transactional joinpoint [" + 
joinpoint 
Identification + 


"] because no transaction manager has been configured"); 


} 
/根据 指定 的 属性 与 status 准 备 一 个 TransactionInfo 
return prepareTransactionInfo(tm, txAttr, joinpointIdentification, 
status); 
} 
X createTransactionIfNecessarbk] x 3c Fit T 3x EJ LFS Tie 
(1) 使 用 DelegatingTransactionAttribute 封 装 传 入 的 
TransactionAttribute 实 例 。 
对 于 传 入 的 TransactionAttribute 类 型 的 参数 txAttr， 当 前 的 实际 类 
型 是 RuleBasedTransaction Attribute ， 是 由 获取 事务 属性 时 生成 ， 主 要 


用 于 数据 承载 ， 而 这 里 之 所 以 使 用 Delegating TransactionAttribute 进 行 
封装 ， 当 然 是 提供 了 更 多 的 功能 。 
(2) 获取 事务 。 
事务 处 理 当 然 是 以 事务 为 核心 ， 那 么 获取 事务 就 是 最 重要 的 事 


(3) 构建 事务 信息 。 
根据 之 前 几 个 步骤 获取 的 信息 构建 TransactionInfo 并 返回 。 
我 们 分 别 对 以 上 步骤 进行 详细 的 解析 。 
1. 获取 事务 
Spring 中 使 用 getTransaction 来 处 理事 务 的 准备 工作 ， 包 括 事务 获 
取 以 及 信息 的 构建 。 
public final TransactionStatus getTransaction(TransactionDefinition 
definition) throws 
TransactionException 1 
Object transaction = doGetTransaction(); 
// Cache debug flag to avoid repeated checks. 
boolean debugEnabled = logger.isDebugEnabled(); 
if (definition == null) { 
// Use defaults if no transaction definition given. 
definition = new Default TransactionDefinition(); 
j 
// 判 断 当 前 线程 是 否 存在 事务 ， 判 读 依据 为 当前 线程 记录 的 连接 
不 为 空 且 连接 中 (connectionHolden 中 的 
transactionActive 属 性 不 为 空 


if (isExistingTransaction(transaction)) 1 


/当前 线程 已 经 存在 事务 


return handleExistingTransaction(definition, transaction, 
debugEnabled); 
l 
/事务 超时 设置 验证 
if (definition.getTimeout() < 
TransactionDefinition.TIMEOUT DEFAULT) { 
throw new InvalidTimeoutException(" Invalid transaction 
timeout", 
definition.getTimeout()); 
j 
/如 果 当 前 线程 不 存在 事务 ， 但 是 propagationBehavior 却 被 声明 
为 PROPAGATION_MANDATIORY 抛 
te 
if (definition. getPropagationBehavior() == TransactionDefinition. 
PROPAGATION_ 
MANDATORY) { 
throw new Illegal TransactionStateException( 
"No existing transaction found for transaction marked with 
propagation 'mandatory""); 
Jelse if (definition.getPropagationBehavior() == 
TransactionDefinition. 
PROPAGATION REQUIRED || 
definition.getPropagationBehavior() == TransactionDefinition. 
PROPAGATION 
REQUIRES NEW || 
definition.getPropagationBehavior() == 
TransactionDefinition.PROPAGATION NESTED) { 


//PROPAGATION_REQUIRED. 
PROPAGATION_REQUIRES_NEW、PROPAGATION_NESTED 都 需 
新 建 事 务 
// 空 挂 起 
SuspendedResourcesHolder suspendedResources = 
suspend(null); 
if (debugEnabled) { 
logger.debug( Creating new transaction with name [" + 
definition. 
getName() + "]: " + definition); 
j 
try { 
boolean newSynchronization = 
(getTransactionSynchronization() != 
SYNCHRONIZATION NEVER); 
DefaultTransactionStatus status = newTransactionStatus( 
definition, transaction, true, newSynchronization, 
debugEnabled, 
suspendedResources); 
/* 
* 构造 transaction ,包括 设置 ConnectionHolder、 陋 离 级 
别 、timonut 
* 如 果 是 新 连接 ， 绑 定 到 当前 线程 
i 
doBegin(transaction, definition); 
/新 同步 事务 的 设置 ， 针 对 于 当前 线程 的 设置 


prepareSynchronization(status, definition); 


return status; 

j 

catch (RuntimeException ex) 1 
resume(null, suspendedResources); 
throw ex; 

j 

catch (Error err) 1 
resume(null, suspendedResources); 


throw err; 


} 
else { 
// Create "empty" transaction: no actual transaction, but 
potentially 
synchronization. 


boolean newSynchronization = (getTransactionSynchronization() 


SYNCHRONIZATION_ALWAYS); 
return prepareTransactionStatus(definition, null, true, 
newSynchronization, 
debugEnabled, null); 
} 
} 
当然 ， 在 Spring 中 每 个 复杂 的 功能 实现 ， 并 不 是 一 次 完成 的 ， 而 
是 会 通过 入 口 函 数 进行 一 个 框架 的 搭建 ， 初 步 构建 完整 的 逻辑 ， 而 将 
实现 细节 分 摊 给 不 同 的 溯 数 。 那 么 ， 让 我 们 看 看 事务 的 准备 工作 都 包 
括 哪些 


(1) 获取 事务 
创建 对 应 的 事务 实例 ， 这 里 使 用 的 是 
DataSourceTransactionManager 中 的 doGetTransaction 方 法 ， 创 建 基于 
JDBC 的 事务 实例 。 如 果 当 前 线程 中 存在 关于 dataSource 的 连接 ， 那 么 
直接 使 用 。 这 里 有 一 个 对 保存 点 的 设置 ， 是 否 开启 允许 保存 点 取决 于 
ERRE S RIFRAF Z. 
protected Object doGetTransaction() 1 
DataSourceTransactionObject txObject = new 
DataSourceTransactionObject(); 
txObject.setSavepointAllowed(isNestedTransactionAllowed()); 
/如 果 当 前 线程 已 经 记录 数据 库 连 接 则 使 用 原 有 连接 
ConnectionHolder conHolder = 
(ConnectionHolder) 
TransactionSynchronizationManager.getResource(this.dataSource); 
//false 表 示 非 新 创建 连接 。 
txObject.setConnectionHolder(conHolder, false); 


return txObject; 


(2) MRASAAEFESS, WIERHSPERESXSS NUE. 

(3) 事务 超时 设置 验证 。 

(4) 事务 propagationBehavior 属 性 的 设置 验证 。 

(5) 构建 DefaultTransactionStatuso 

(6) 完善 transaction， 包 括 设 置 ConnectionHolder、 隔离 级 别 、 
timeout， 如 果 是 新 连接 ， 则 绑 定 到 当前 线程 。 

对 于 一 些 隔离 级 别 、timeonut 等 功能 的 设置 并 不 是 由 Spring 来 完成 
的 ， 而 是 委托 给 底层 的 数据 库 连接 去 做 的 ， 而 对 于 数据 库 连 接 的 设置 
就 是 在 doBegin 了 国 数 中 处 理 的 。 


/炒米 


* 构造 transaction, 包 括 设置 ConnectionHolder、 隔 离 级 别 、 
timeout 
* 如 果 是 新 连接 ， 绑 定 到 当前 线程 
ai) 
@Override 
protected void doBegin(Object transaction, TransactionDefinition 
definition) { 
DataSourceTransactionObject txObject = 
(DataSourceTransactionObject) transaction; 
Connection con = null; 
try { 
if (txObject.getConnectionHolder() == null || 


txObject.getConnectionHolder().isSynchronizedWithTransaction()) { 
Connection newCon = this.dataSource.getConnection(); 
if (logger.isDebugEnabled()) 1 
logger.debug(" Acquired Connection [" + newCon + "] for 
JDBC transaction"); 
j 
txObject.setConnectionHolder(new ConnectionHolder(newCon), 


true); 


txObject.getConnectionHolder().setS ynchronizedWithTransaction(true); 


con = txObject.getConnectionHolder().getConnection(); 
/设置 隔离 级 别 


Integer previousIsolationLevel = 


DataSourceUtils.prepareConnection 
ForTransaction(con, definition); 
txObject.setPreviousIsolationLevel(previousIsolationLevel); 
/更 改 自动 提交 设置 ， 由 Spring 控制 提交 
if (con.getAutoCommit()) { 

txObject.setMustRestoreAutoCommit(true); 
if (logger.isDebugEnabled()) { 
logger.debug(" Switching JDBC Connection [" + con + "] to 


manual commit"); 


} 


con.setAutoCommit(false); 


j 
/设置 判断 当前 线程 是 否 存在 事务 的 依据 
txObject.getConnectionHolder().setTransactionActive(true); 


int timeout = determineTimeout(definition); 
if (timeout != TransactionDefinition. TIMEOUT_DEFAULT) { 


txObject.getConnectionHolder().setTimeoutInSeconds(timeout); 
} 
// Bind the session holder to the thread. 
if (txObject.isNewConnectionHolder()) { 
/将 当前 获取 到 的 连接 绑 定 到 当前 线程 


TransactionS ynchronizationManager.bindResource(getDataSource(), 


txObject.getConnectionHolder()); 


j 
catch (Exception ex) 1 
DataSourceUtils.releaseConnection(con, this.dataSource); 
throw new CannotCreateTransactionException("Could not open 
JDBC Connection 


for transaction", ex); 


} 

可 以 说 事务 是 从 这 个 函数 开始 的 ， 因 为 在 这 个 函数 中 已 经 开始 党 
试 了 对 数据 库 连 接 的 获取 ， 当 然 ， 在 获取 数据 库 连 接 的 同时 ， 一 些 必 
要 的 设置 也 是 需要 同步 设置 的 。 

n 尝试 获取 连接 。 

当然 并 不 是 每 次 都 会 获取 新 的 连接 ， 如 果 当 前 线程 中 的 
connectionHolder 已 经 存在 ， 则 没有 必要 再 次 获取 ， 或 者 ， 对 于 事务 同 
步 表 示 设 置 为 true 的 需要 重新 获取 连接 。 

o 设置 隔离 级 别 以 及 只 读 标识 。 

你 是 否 有 过 这 样 的 错觉 ? 事务 中 的 只 读 配置 是 Spring 中 做 了 一 些 
处 理 呢 ? Spring 中 确实 是 针对 只 读 操作 做 了 一 些 处 理 ， 但 是 核心 的 实 
现 是 设置 connection 上 的 readOnly 属 性 。 同 样 ， 对 于 隔离 级 别 的 控制 也 
是 交 由 connection 去 控制 的 。 

p 更 改 默认 的 提交 设置 。 

如 果 事 务 属性 是 自动 提交 ， 那 么 需要 改变 这 种 设置 ， 而 将 提交 操 


作 委 托 给 Spring 来 处 理 。 
q 设置 标志 位 ， 标 识 当前 连接 已 经 被 事务 激活 。 
r 设置 过 期 时 间 。 


s 将 connectionHolder 绑 定 到 当前 线程 。 


设置 隔离 级 别 的 prepareConnectionForTransaction 名 数 用 于 负责 对 
底层 数据 库 连 接 的 设置 ， 当 然 ， 只 是 包含 只 读 标识 和 隔离 级 别 的 设 
置 。 由 于 强大 的 日 志 及 异常 处 理 ， 显 得 函数 代码 量 比较 大 ， 但 是 单 从 
业务 角度 去 看 ， 关 键 代 码 其 实 是 不 多 的 。 

public static Integer prepareConnectionForTransaction(Connection 
con, Transaction Definition 

definition) 

throws SQLException 1 

Assert.notNull(con, "No Connection specified"); 

/设置 数据 连接 的 只 读 标识 

if (definition != null && definition.isReadOnly()) { 

try { 
if (logger.isDebugEnabled()) 1 
logger.debug(" Setting JDBC Connection [" + con + "| read- 
only"); 
j 
con.setReadOnly(true); 
} 
catch (SQLException ex) { 
Throwable exToCheck = ex; 
while (exToCheck != null) { 
if 
(exToCheck.getClass().getSimpleName().contains(""Timeout")) 1 
// Assume it's a connection timeout that would otherwise get 
lost: e.g. from JDBC 4.0 


throw ex; 


exToCheck = exToCheck.getCause(); 


j 
logger.debug(" Could not set JDBC Connection read-only", ex); 


j 
catch (RuntimeException ex) 1 
Throwable exToCheck - ex; 
while (exToCheck != null) { 
if 
(exToCheck.getClass().getSimpleName().contains(""Timeout")) 1 


throw ex; 
} 
exToCheck = exToCheck.getCause(); 
} 
logger.debug(" Could not set JOBC Connection read-only", ex); 


} 
/设置 数据 库 连 接 的 隔离 级 别 
Integer previousIsolationLevel = null; 
if (definition != null && definition.getIsolationLevel() != Transaction 
Definition.ISOLATION DEFAULT) { 
if (logger.isDebugEnabled()) 1 
logger.debug(" Changing isolation level of JDBC Connection [" + 
con + "]to "+ 

definition.getIsolationLevel()); 

j 

int currentIsolation = con.getTransactionIsolation(); 


if (currentIsolation != definition.getIsolationLevel()) 1 


previousIsolationLevel = currentIsolation; 


con.setTransactionlIsolation(definition.getIsolationLevel()); 


j 
return previousIsolationLevel; 
j 
(7) 将 事务 信息 记录 在 当前 线程 中 。 
protected void prepareSynchronization(DefaultTransactionStatus 
status, Transaction 
Definition definition) { 


if (status.isNewSynchronization()) 1 


TransactionSynchronizationManager.setA ctual TransactionA ctive(status. 


hasTransaction()); 


TransactionSynchronizationManager.setCurrentTransactionIsolationLevel( 
(definition.getIsolationLevel() != 

TransactionDefinition. ISOLATION . 
DEFAULT) ? 


definition.getIsolationLevel() : null); 
TransactionSynchronizationManager.setCurrentTransactionReadOnly 
(definition. 


isReadOnly()); 


TransactionSynchronizationManager.setCurrentTransactionName(definition 


getName()); 


TransactionS ynchronizationManager.initS ynchronization(); 


} 
2. 处 理 已 经 存在 的 事务 
之 前 讲述 了 普通 事务 建立 的 过 程 ， 但 是 Spring 中 支持 多 种 事务 的 
传播 规则 ， 比 如 PROPAGATION_NESTED、 
PROPAGATION_REQUIRES_NEW 等 ， 这 些 都 是 在 已 经 存在 事务 的 基 
础 上 进行 进一步 的 处 理 ， 那 么 ， 对 于 已 经 存在 的 事务 ， 准 备 操作 是 如 
何 进行 的 呢 ? 
private TransactionStatus handleExisting Transaction( 
TransactionDefinition definition, Object transaction, boolean 
debugEnabled) 
throws TransactionException 1 
if (definition.getPropagationBehavior() == 
TransactionDefinition.PROPAGATION NEVER) { 
throw new Illegal TransactionStateException( 
"Existing transaction found for transaction marked with 
propagation 
never"); 
j 
if (definition.getPropagationBehavior() == 
TransactionDefinition.PROPAGATION NOT . 
SUPPORTED) { 
if (debugEnabled) { 


logger.debug( Suspending current transaction"); 


Object suspendedResources = suspend(transaction); 
boolean newSynchronization = (getTransactionSynchronization() 
-- SYNCHRONIZATION 
ALWAY S); 
return prepareTransactionStatus( 
definition, null, false, newSynchronization, debugEnabled, 
suspendedResources); 
j 
if (definition.getPropagationBehavior() == 
TransactionDefinition. PROPAGATION _ 
REQUIRES_NEW) { 
if (debugEnabled) { 
logger.debug("Suspending current transaction, creating new 
transaction 
with name [" + 
definition.getName() + "]"); 
} 
/新 事务 的 建立 
SuspendedResourcesHolder suspendedResources = 
suspend(transaction); 
try { 


boolean newSynchronization = (getTransactionSynchronization() 


SYNCHRONIZATION_NEVER); 
DefaultTransactionStatus status = newTransactionStatus( 
definition, transaction, true, newSynchronization, debugEnabled, 


suspendedResources); 


doBegin(transaction, definition); 
prepareSynchronization(status, definition); 
return status; 
j 
catch (RuntimeException beginEx) 1 
resumeA fterBeginException(transaction, suspendedResources, 
beginEx); 
throw beginEx; 
} 
catch (Error beginErr) { 
resumeA fterBeginException(transaction, suspendedResources, 
beginErr); 


throw beginErr; 


} 
BRATS SS BY EB 
if (definition. getPropagationBehavior() == 
TransactionDefinition. PROPAGATION _ 
NESTED) { 
if (lisNestedTransactionAllowed()) { 
throw new NestedTransactionNotSupportedException( 
"Transaction manager does not allow nested transactions by 
default - " + 
"specify 'nestedTransactionAllowed' property with value 'true""); 
} 
if (debugEnabled) { 


logger.debug(" Creating nested transaction with name [" + 


definition.getName() + "]"); 
} 
if (useSavepointForNestedTransaction()) { 
/如 果 没 有 可 以 使 用 保存 点 的 方式 控制 事务 回 滚 ， 那 么 在 
入 式 事 务 的 建立 初始 建立 保存 点 


DefaultTransactionStatus status = 


SH 


prepareTransactionStatus(definition, transaction, false, 
false, debugEnabled, null); 
status.createAndHoldSavepoint(); 
return status; 

jelse { 


/有 些 情况 是 不 能 使 用 保存 点 操作 ， 比 如 JTA， 那 么 建立 新 事 
物 


boolean newSynchronization = (getTransactionSynchronization() 


SYNCHRONIZATION NEVER); 
DefaultTransactionStatus status = new TransactionStatus( 


definition,transaction, true, newSynchronization, 
debugEnabled, null); 


doBegin(transaction, definition); 


prepareSynchronization(status, definition); 


return status; 


j 
if (debugEnabled) { 


logger.debug(" Participating in existing transaction"); 


if (is ValidateExistingTransaction()) 1 
if (definition.getIsolationLevel() != 
TransactionDefinition. PROPAGATION _ 
REQUIRES_NEW) { 
Integer currentIsolationLevel = 
TransactionSynchronizationManager. 
getCurrentTransactionIsolationLevel(); 
if (currentIsolationLevel == null || currentIsolationLevel != 
definition.getIsolationLevel()) { 
Constants isoConstants — 
DefaultTransactionDefinition.constants; 
throw new IllegalTransactionStateException(" Participating 
transaction 
with definition [" + 
definition + "] specifies isolation level which is 
incompatible with existing transaction: " + 
(currentIsolationLevel != null ? 
isoConstants.toCode(currentIsolationLevel, 
DefaultTransactionDefinition.PREFIX. ISOLATION) : 


"(unknown)")); 


} 
if (!definition.isReadOnly()) { 
if 


(TransactionSynchronizationManager.isCurrentTransactionReadOnly()) { 


throw new IllegalTransactionStateException(" Participating 
transaction 

with definition [" + 

definition + "] is not marked as read-only but existing 


transaction is"); 


j 
j 
boolean newSynchronization = (getTransactionSynchronization() 
I= SYNCHRONIZATION . 
NEVER); 
return prepareTransactionStatus(definition, transaction, false, 
newSynchronization, 
debugEnabled, null); 
j 
对 于 已 经 人 存在 事务 的 处 理 过 程 中 ， 我 们 看 到 了 很 多 熟悉 的 操作 ， 
但 是 ， 也 有 些 不 同 的 地 方 ， 立 数 中 对 已 经 存在 的 事务 处 理 考虑 两 种 情 
Zo 
(1) PROPAGATION REQUIRES NEW 表示 当前 方法 必须 在 它 
自己 的 事务 里 运行 ， 一 个 新 的 事务 将 被 启动 ， 而 如 果 有 一 个 事务 正在 
运行 的 话 ， 则 在 这 个 方法 运行 期 间 被 挂 起 。 而 Spring 中 对 于 此 种 传播 
方式 的 处 理 与 新 事务 建立 最 大 的 不 同 点 在 于 使 用 suspend 方 法 将 原 事务 
挂 起 。 将 信息 挂 起 的 目的 当然 是 为 了 在 当前 事务 执行 完毕 后 在 将 原 事 
(2) PROPAGATION_NESTED 表示 如 果 当 前 正 有 一 个 事务 在 运 
行 中 ， 则 该 方法 应 该 运行 在 一 个 褒 套 的 事务 中 ， 被 赔 套 的 事务 可 以 独 
立 于 封装 事务 进行 提交 或 者 回 滚 ， 如 果 封装 事务 不 存在 ， 行 为 就 像 


PROPAGATION REQUIRES NEW. XPFFHUNIUGRBSSBJANS, Spring 
中 主要 考虑 了 两 种 方式 的 处 理 。 

Spring 中 允许 人 散 入 事务 的 时 候 ， 则 首选 设置 保存 点 的 方式 作为 异 
单 处 理 的 回 滚 。 

对 于 其 他 方式 ， 比 如 JTA 无 法 使 用 保存 点 的 方式 ， 那 么 处 理 方式 
与 PROPAGATION_REQUIRES_NEW 相 同 ， 而 一 旦 出 现 异 常 ， 则 由 
Spring 的 事务 异常 处 理 机 制 去 完成 后 续 操 作 。 

对 于 挂 起 操作 的 主要 目的 是 记录 原 有 事务 的 状态 ， 以 便于 后 续 操 
作对 事务 的 恢复 : 

protected final SuspendedResourcesHolder suspend(Object 
transaction) throws Transaction 

Exception { 


if (TransactionSynchronizationManager.isSynchronizationA ctive()) 


{ 

List<TransactionSynchronization> suspendedSynchronizations = 
doSuspend 

Synchronization(); 

try { 


Object suspendedResources = null; 
if (transaction != null) { 
suspendedResources = doSuspend(transaction); 
} 
String name = TransactionSynchronizationManager. 
GetCurrent Transaction 
Name(); 


TransactionS ynchronizationManager.setCurrentTransactionName(null); 


boolean readOnly = 
TransactionS ynchronizationManager.isCurrent Transaction 
ReadOnly(); 


TransactionS ynchronizationManager.setCurrentTransactionReadOnly(false) 
Integer isolationLevel = 
TransactionS ynchronizationManager.getCurrent 


TransactionIsolationLevel(); 


TransactionS ynchronizationManager.setCurrentTransactionIsolation 
Level(null); 
boolean wasActive = 

TransactionS ynchronizationManager.isActual 


TransactionActive(); 


TransactionS ynchronizationManager.setA ctual TransactionA ctive(false); 
return new SuspendedResourcesHolder( 
suspendedResources, suspendedSynchronizations, name, 

readOnly, 
isolationLevel, wasActive); 

j 

catch (RuntimeException ex) 1 
// doSuspend failed - original transaction is still active... 
doResumeSynchronization(suspendedS ynchronizations); 


throw ex; 


catch (Error err) 1 
doResumeSynchronization(suspendedS ynchronizations); 


throw err; 


j 
else if (transaction != null) { 
Object suspendedResources = doSuspend(transaction); 
return new SuspendedResourcesHolder(suspendedResources); 
j 
else { 


return null; 


j 
3. 准备 事务 信 s 
当 已 经 建立 事务 连接 并 完成 了 事务 信息 的 提取 后 ， 我 们 需要 将 所 
有 的 事务 信息 统一 记录 在 TransactionInfo 类 型 的 实例 中 ， 这 个 实例 包 
含 了 目标 方 法 开始 前 前 的 所 有 状态 信息 ， 一 旦 SAU Spring 会 
通过 TransactionInfo 类 型 的 实例 中 的 信息 来 进行 回 滚 等 后 续 工 作 。 
protected TransactionInfo 
prepareTransactionInfo(PlatformTransactionManager tm, 
TransactionAttribute txAttr, String joinpointIdentification, Transaction 
Status status) 1 
TransactionInfo txInfo = new TransactionInfo(tm, tx A ttr, 
joinpointIdentification); 
if (txAttr != null) 1 
// We need a transaction for this method 


if (logger.isTraceEnabled()) { 


logger.trace("Getting transaction for [" + txInfo.getJoinpoint 
Identification() + "]"); 
j 
/记录 事务 状态 
txInfo.new TransactionStatus(status); 
i 
else { 
if (logger.isTraceEnabled()) 
logger.trace("Don't need to create transaction for [" + joinpoint 


Identification + 


"|: This method isn't transactional."); 
} 
txInfo.bindToThread(); 


return txInfo; 


之 前 已 经 完成 了 目标 方法 运行 前 的 事务 准备 工作 ， 而 这 些 准备 工 
作 最 大 的 目的 无 非 是 对 于 程序 没有 按照 我 们 期 待 的 那样 进行 ， 也 融 是 
出 现 特定 的 错误 ， 那 么 ， 当 出 现 错误 的 时 候 ，Spring 是 怎么 对 数据 进 
行 恢复 的 呢 ? 
protected void completeTransactionAfterThrowing(TransactionInfo 
txInfo, Throwable ex) { 
// 当 抛 出 异常 时 首先 判断 当前 是 否 存 在 事务 ， 这 是 基础 依据 
if (txInfo != null && txInfo.hasTransaction()) { 
if (logger.isTraceEnabled()) 1 


Identification() + 


logger.trace("Completing transaction for [" * 
txInfo.getJoinpoint 
"] after exception: " * ex); 
j 
/这 里 判断 是 否 回 滚 默认 的 依据 是 抛 出 的 异常 是 否 是 
RuntimeException 或 者 是 Error 的 类 型 
if (txInfo.transactionAttribute.rollbackOn(ex)) { 
try 1 
/根据 TransactionStatus 信 息 进 行 回 滚 处 理 


txInfo.getTransactionManager().rollback(txInfo.GetTransaction 

Status()); 

} 

catch (TransactionSystemException ex2) { 
logger.error(" Application exception overridden by rollback 
exception", ex); 
ex2.initApplicationException(ex); 
throw ex2; 

} 

catch (RuntimeException ex2) { 
logger.error(" Application exception overridden by rollback 
exception", ex); 
throw ex2; 

} 

catch (Error err) { 
logger.error(" Application exception overridden by rollback 


error", ex); 


throw err; 


j 

yelse 1 
/如 果 不 满足 回 滚 条 件 即 使 抛 出 异常 也 同样 会 提交 
try { 


txInfo.getTransactionManager().commit(txInfo.getTransactionStatus()); 
} 
catch (TransactionSystemException ex2) { 
logger.error(" Application exception overridden by commit 
exception", ex); 
ex2.initApplicationException(ex); 
throw ex2; 
} 
catch (RuntimeException ex2) { 
logger.error(" Application exception overridden by commit 
exception", ex); 
throw ex2; 
j 
catch (Error err) 1 
logger.error(" Application exception overridden by commit 
error", ex); 


throw err; 


在 对 目标 方法 的 执行 过 程 中 ， 一 旦 出 现 Throwable 就 会 被 引导 至 此 
方法 处 理 ， 但 是 并 不 代表 所 有 的 Throwable 都 会 被 回 滚 处 理 ， 比 如 我 
们 最 常用 的 Exception， 默 认 是 不 会 被 处 理 的 。 黑 认 情 况 下 ， 即 使 出 现 
异常 ， 数 据 也 会 被 正常 提交 ， 而 这 个 关键 的 地 方 就 是 在 
txInfo.transaction Attribute.rollbackOn(ex) 这 个 水 数 。 

1. ERR 

public boolean rollbackOn(Throwable ex) 1 

return (ex instanceof RuntimeException || ex instanceof Error); 

j 

看 到 了 吗 ?默认 情况 下 Spring 中 的 事务 异常 处 理 机 制 只 对 
RuntimeException 和 Error 两 种 情况 感 兴趣 ， 当 然 你 可 以 通过 扩展 来 改 
变 ， 不 过 ， 我 们 最 常用 的 还 是 使 用 事务 提供 的 属性 设置 ， 利 用 注解 方 
式 的 使 用 ， 例 如 : 

(9 Transactional(propagation-Propagation. REQUIRED,rollbackFor-E 
xception.class) 

2. 回 滚 处 理 

当然 ， 一 旦 符合 回 滚 条 件 ， 那 么 Spring 就 会 将 程序 引导 至 回 滚 处 
EB REN, 

public final void rollback(TransactionStatus status) throws 
TransactionException { 

/如 果 事 务 已 经 完成 ， 那 么 再 次 回 滚 会 抛 出 异常 
if (status.isCompleted()) 1 
throw new Illegal TransactionStateException( 
"Transaction is already completed - do not call commit or 
rollback 


more than once per transaction"); 


DefaultTransactionStatus defStatus = (DefaultTransactionStatus) 
status; 
processRollback(defStatus); 
j 
private void processRollback(DefaultTransactionStatus status) 1 
try { 
try { 
/激活 所 有 TransactionSynchronization 中 对 应 的 方法 
triggerBeforeCompletion(status); 
if (status.hasSavepoint()) 1 
if (status.isDebug()) 1 
logger.debug("Rolling back transaction to savepoint"); 
j 
/如 果 有 保存 点 ， 也 就 是 当前 事务 为 单独 的 线程 则 会 退 
到 保存 点 
status.rollbackToHeldSavepoint(); 
j 
else if (status.isNewTransaction()) 1 
if (status.isDebug()) 1 


logger.debug("Initiating transaction rollback"); 


} 
/如 果 当 前 事务 为 独立 的 新 事物 ， 则 直接 回 退 
doRollback(status); 

j 


else if (status.hasTransaction()) { 
if (status.isLocalRollbackOnly() || 
isGlobalRollbackOnParticipation 


Failure()) 1 
if (status.isDebug()) 1 
logger.debug(" Participating transaction failed - 
marking existing transaction as rollback-only"); 
j 
/如 果 当 前 事务 不 是 独立 的 事务 ， 那 么 只 能 标记 状态 ， 
等 到 事务 链 执行 完毕 后 统 
一 回 滚 
doSetRollbackOnly(status); 
j 
else { 
if (status.isDebug()) 1 
logger.debug(" Participating transaction failed - 


letting transaction originator decide on rollback"); 


j 
else { 
logger.debug( Should roll back transaction but cannot - no 


transaction available"); 


} 
catch (RuntimeException ex) { 
triggerAfterCompletion(status, 
TransactionSynchronization.STATUS UNKNOWN); 


throw ex; 


catch (Error err) 1 
triggerAfterCompletion(status, 
TransactionSynchronization.STATUS UNKNOWN); 
throw err; 
} 
/激活 所 有 TransactionSynchronization 中 对 应 的 方法 
triggerAfterCompletion(status, 
TransactionSynchronization.STATUS ROLLED BACK); 
} 
finally { 
/清空 记录 的 资源 并 将 挂 起 的 资产 恢复 
cleanupAfterCompletion(status); 
} 
} 
同样 ， 对 于 在 Spring 中 的 复杂 的 逻辑 处 理 过 程 ， 在 入 口 遂 数 一 般 
都 会 给 出 个 整体 的 处 理 脉 络 ， 而 把 实现 细节 委托 给 其 他 函数 去 执行 。 
我 们 尝试 总 结 下 Spring 中 对 于 回 深 处 理 的 大 致 脉络 如 下 。 
(1) 首先 是 自 定 义 触发 器 的 调用 ， 包 括 在 回 滚 前 、 完 成 回 滚 后 的 
， 当 然 完成 回 滚 包 括 正常 回 滚 与 回 滚 过 程 中 出 现 异 常 ， 自 定义 的 
ui i iE 而 对 于 触发 器 的 注册 ， 常 见 是 
在 回调 过 程 中 通过 TransactionSynchronizationManager 类 中 的 静态 方法 
直接 注册 : 
public static void registerSynchronization(TransactionSynchronization 
synchronization) 
(2) 除了 触发 监听 阅 数 外 ， 就 是 真正 的 回 滚 逻辑 处 理 了 。 
当 之 前 已 经 保存 的 事务 信息 中 有 保存 点 信息 的 时 候 ， 使 用 保存 点 
RATE A. BATFRANSS, WRATH SAME, AER 


的 事务 异 单 并 不 会 引起 外 部 事务 的 回 滚 。 
根据 保存 点 回 滚 的 实现 方式 其 实 是 根据 底层 的 数据 库 连 接 进行 
的 。 
public void rollbackToHeldSavepoint() throws TransactionException 1 
if (!IhasSavepoint()) { 
throw new TransactionUsageException("No savepoint associated 
with current 
transaction"); 
j 
getSavepointManager().rollbackToSavepoint(getSavepoint()); 
setSavepoint(null); 
j 
这 里 使 用 的 是 JDBC 的 方式 进行 数据 库 连 接 ， 那 么 
getSavepointManager()EK[ 2X38 [B]B] ze. JdbcTransactionObjectSupport , tH, 
Roe we E ER US FH JdbcTransactionObjectSupport 中 的 
rollbackToSavepoint73 7&o 
public void rollbackToSavepoint(Object savepoint) throws 
TransactionException 1 


try { 


getConnectionHolderForSavepoint().getConnection().rollback((Savepoint) 
savepoint); 
i 
catch (Throwable ex) { 
throw new TransactionSystemException(" Could not roll back to 
JDBC savepoint", ex); 
} 


j 
当 之 前 已 经 保存 的 事务 信息 中 的 事务 为 新 事物 ， 那 么 直接 回 滚 。 
单 用 于 单独 事务 的 处 理 。 对 于 没有 保存 点 的 回 滚 ，Spring 同 样 是 使 用 
底层 数据 库 连 接 提供 的 API 来 操作 的 。 由 于 我 们 使 用 的 是 
DataSourceTransactionManager， 那 么 doRollback 遂 数 会 使 用 此 类 中 的 实 
现 : 
protected void doRollback(DefaultTransactionStatus status) 1 
DataSourceTransactionObject txObject = 
(DataSourceTransactionObject) 
status.getTransaction(); 
Connection con = 
txObject.getConnectionHolder().getConnection(); 
if (status.isDebug()) { 
logger.debug("Rolling back JDBC transaction on Connection [" 
+ con + "]"); 
} 
try { 
con.rollback(); 
i 
catch (SQLException ex) { 
throw new TransactionSystemException("Could not roll back 
JDBC transaction", ex); 
lj 
j 
当前 事务 信息 中 表明 是 存在 事务 的 ， 又 不 属于 以 上 两 种 情况 ， 多 
数 用 于 JITA， 只 做 回 滚 标 识 ， 等 到 提交 的 时 候 统 一 不 提交 。 
3. 回 滚 后 的 信息 清除 


对 于 回 滚 逻 辑 执行 结束 后 ， 无 论 回 滚 是 否 成 功 ， 都 必须 要 做 的 事 
情 融 是 事务 结束 后 的 收尾 工作 。 


private void cleanupAfterCompletion(DefaultTransactionStatus status) 


/设置 完成 状态 
status.setCompleted(); 
if (status.isNewSynchronization()) 1 
TransactionS ynchronizationManager.clear(); 
} 
if (status.isNewTransaction()) { 
doCleanupAfterCompletion(status.get Transaction()); 
j 
if (status.getSuspendedResources() != null) 1 
if (status.isDebug()) 1 
logger.debug("Resuming suspended transaction after 
completion of inner 
transaction"); 
j 
/结束 之 前 事务 的 挂 起 状态 
resume(status.getTransaction(), (SuspendedResourcesHolder) 
status.getSuspended 


Resources()); 


) 
MRA, BS MMBAU ELIE T EHE KAA 
(1) 设置 状态 是 对 事务 信息 作 完 成 标识 以 避免 重复 调用 。 


(2) 如 果 当 前 事务 是 新 的 同步 状态 ， 需 要 将 绑 定 到 当前 线程 的 事 
务 信息 清除 。 
(3) 如 果 是 新 事物 需要 做 些 清除 资源 的 工作 。 
protected void doCleanupAfterCompletion(Object transaction) 1 
DataSourceTransactionObject txObject = 
(DataSourceTransactionObject) transaction; 


if (txObject.isNewConnectionHolder()) 1 
/将 数据 库 连 接 从 当前 线程 中 解除 绑 定 


TransactionSynchronizationManager.unbindResource(this.dataSource); 
j 
FRIRE 
Connection con = 
txObject.getConnectionHolder().getConnection(); 
try { 
if (txObject.isMustRestoreAutoCommit()) 1 
// 恢 复数 据 库 连接 的 自动 提交 属性 
con.setAutoCommit(true); 
} 
// 重 置 数 据 库 连 接 
DataSourceUtils.resetConnectionAfterTransaction(con, 
txObject.getPrevious 
IsolationLevel()); 
j 
catch (Throwable ex) 1 
logger.debug(" Could not reset JDBC Connection after 


transaction", ex); 


j 
if (txObject.isNewConnectionHolder()) 1 
if (logger.isDebugEnabled()) 1 
logger.debug("Releasing JDBC Connection [" + con + "] after 
transaction"); 
j 
/如 果 当 前 事务 时 独立 的 新 创建 的 事务 则 在 事务 完成 时 释放 
效 据 库 连接 
DataSourceUtils.releaseConnection(con, this.dataSource); 
j 
txObject.getConnectionHolder().clear(); 
j 
(4) 如 果 在 事务 执行 前 有 事务 挂 起 ， 那 么 当前 事务 执行 结束 后 需 
要 将 挂 起 事务 恢复 。 
protected final void resume(Object transaction, 
SuspendedResourcesHolder resourcesHolder) 
throws TransactionException 1 
if (resourcesHolder !- null) { 
Object suspendedResources = 
resourcesHolder.suspendedResources; 
if (suspendedResources != null) { 
doResume(transaction, suspendedResources); 
i 
List<TransactionSynchronization> suspendedSynchronizations = 
resourcesHolder. 
suspendedSynchronizations; 


if (suspendedSynchronizations != null) { 


TransactionSynchronizationManager.setA ctualTransactionActive (resources 


Holder.wasA ctive); 


TransactionSynchronizationManager.setCurrentTransactionIsolationLevel 


(resourcesHolder.isolationLevel); 


TransactionS ynchronizationManager.setCurrentTransactionReadOnly 


(resourcesHolder.readOnly); 


TransactionS ynchronizationManager.setCurrentTransactionName 
(resourcesHolder.name); 


doResumeSynchronization(suspendedS ynchronizations); 


} 
10.3.3 事务 提交 


之 前 我 们 分 析 了 Spring 的 事务 异 单 处 理 机 制 ， 那 么 事务 的 执行 并 
没有 出 现任 何 的 异常 ， 也 就 意味 着 事务 可 以 走 正 常事 务 提 交 的 流程 
了 。 

protected void commitTransactionAfterReturning(TransactionInfo 
txInfo) { 

if (txInfo != null && txInfo.hasTransaction()) 1 
if (logger.isTraceEnabled()) 1 
logger.trace("Completing transaction for [" + 


txInfo.getJoinpoint 


Identification() + "]"); 


txInfo.getTransactionManager().commit(txInfo.getTransactionStatus()); 
} 

} 

在 真正 的 数据 提交 之 前 ， 还 需要 做 个 判断 。 不 知道 大 家 还 有 没有 
印象 ， 在 我 们 分 析 事 务 异常 处 理 规则 的 时 候 ， 当 某 个 事务 既 没 有 保存 
点 又 不 是 新 事物 ，Spring 对 它 的 处 理 方式 只 是 设置 一 个 回 滚 标 识 。 这 
个 回 深 标识 在 这 里 就 会 派 上 用 场 了 ， 主 要 的 应 用 场景 如 下 。 

某 个 事务 是 另 一 个 事务 的 能 入 事务 ， 但 是 ， 这 些 事务 又 不 在 
Spring 的 管理 范围 内 ， 或 者 无 法 设置 保存 点 ， 那 么 Spring 会 通过 设置 
回 滚 标识 的 方式 来 禁止 提交 。 首 先 当 某 个 仍 入 事务 发 生 回 滚 的 时 候 会 
设置 回 滚 标 识 ， 而 等 到 外 部 事务 提交 时 ， 一 旦 判断 出 当前 事务 流 被 设 
置 了 回 滚 标 识 ， 则 由 外 部 事务 来 统一 进行 整体 事务 的 回 滚 。 

所 以 ， 当 事务 没有 被 异常 捕获 的 时 候 也 并 不 意味 着 一 定 会 执行 提 
交 的 过 程 。 

public final void commit(TransactionStatus status) throws 
TransactionException { 

if (status.isCompleted()) { 
throw new IllegalTransactionStateException( 
"Transaction is already completed - do not call commit or 
rollback 
more than once per transaction"); 
j 
DefaultTransactionStatus defStatus = (DefaultTransactionStatus) 


status; 


// 如 果 在 事务 链 中 已 经 被 标记 回 滚 ， 那 么 不 会 尝试 提交 事务 ， 
直接 回 滚 
if (defStatus.isLocalRollbackOnly()) 1 
if (defStatus.isDebug()) { 
logger.debug(""Transactional code has requested rollback"); 
} 
processRollback(defStatus); 
return; 
} 
if (!shouldCommitOnGlobalRollbackOnly() && 
defStatus.isGlobalRollbackOnly()) { 
if (defStatus.isDebug()) { 
logger.debug("Global transaction is marked as rollback-only 
but 
transactional code requested commit"); 
} 
processRollback(defStatus); 
if (status.isNewTransaction() || 
isFailEarlyOnGlobalRollbackOnly()) { 
throw new UnexpectedRollbackException( 
"Transaction rolled back because it has been marked as 


rollback-only"); 


} 
return; 
} 
/处 理事 务 提 交 


processCommit(defStatus); 


j 
而 当 事 务 执行 一 切 都 正常 的 时 候 ， 便 可 以 真正 地 进入 提交 流程 
了 。 
private void processCommit(DefaultTransactionStatus status) throws 
TransactionException 1 
try { 
boolean beforeCompletionInvoked - false; 
try 1 
// 预 留 
prepareForCommit(status); 
// 添 加 的 TransactionSynchronization 中 的 对 应 方法 的 调用 
triggerBeforeCommit(status); 
// 添 加 的 TransactionSynchronization 中 的 对 应 方法 的 调用 
triggerBeforeCompletion(status); 
beforeCompletionInvoked = true; 
boolean globalRollbackOnly = false; 
if (status.isNewTransaction() || 
isFailEarlyOnGlobalRollbackOnly()) 1 
globalRollbackOnly = status.isGlobalRollbackOnly(); 
j 
if (status.hasSavepoint()) 1 
if (status.isDebug()) 1 
logger.debug(" Releasing transaction savepoint"); 
j 
/如 果 存 在 保存 点 则 清除 保存 点 信息 


status.releaseHeldSavepoint(); 


else if (status.isNewTransaction()) 1 
if (status.isDebug()) 1 


logger.debug("Initiating transaction commit"); 


} 
/如 果 是 独立 的 事务 则 直接 提交 
doCommit(status); 


j 

if (globalRollbackOnly) 1 
throw new UnexpectedRollbackException( 
"Transaction silently rolled back because it has been 


marked as rollback-only"); 


} 
catch (UnexpectedRollbackException ex) { 
triggerAfterCompletion(status, 
TransactionSynchronization.S TATUS — 
ROLLED BACK); 
throw ex; 
} 
catch (TransactionException ex) { 
if (isRollbackOnCommitFailure()) { 
doRollbackOnCommitException(status, ex); 
} 
else { 
triggerAfterCompletion(status, 
TransactionSynchronization.S TATUS . 
UNKNOWN); 


j 
throw ex; 
j 
catch (RuntimeException ex) 1 
if (!beforeCompletionInvoked) { 
triggerBeforeCompletion(status); 
} 
doRollbackOnCommitException(status, ex); 
throw ex; 
} 
catch (Error err) { 
if (!beforeCompletionInvoked) { 
/添加 的 TransactionSynchronization 中 的 对 应 方法 的 调用 
triggerBeforeCompletion(status); 
j 
/提交 过 程 中 出 现 异 常 则 回 滚 
doRollbackOnCommitException(status, err); 
throw err; 
j 
try { 
/添加 的 TransactionSynchronization 中 的 对 应 方法 的 调用 
triggerAfterCommit(status); 
j 
finally { 
triggerAfterCompletion(status, 
TransactionSynchronization.S TATUS _ 
COMMITTED); 


j 

finally { 
cleanupAfterCompletion(status); 

j 

j 

在 提交 过 程 中 也 并 不 是 直接 提交 的 ， 而 是 考虑 了 诸多 的 方面 ， 符 
合 提交 的 条 件 如 下 。 

当 事 务 状态 中 有 保存 点 信息 的 话 便 不 会 去 提交 事务 。 

当 事 务 非 新 事务 的 时 候 也 不 会 去 执行 提交 事务 操作 。 

此 条 件 主要 考虑 内 启事 务 的 情况 ， 对 于 内 窜 事 务 ， 在 Spring 中 正 
常 的 处 理 方式 是 将 内 同事 务 开 始 之 前 设置 保存 点 ， 一 旦 内 同事 务 出 现 
异常 便 根据 保存 点 信息 进行 回 滚 ， 但 是 如 果 没 有 出 现 异 常 ， 内 散 事 务 
并 不 会 单独 提交 ， 而 是 根据 事务 流 由 最 外 层 事务 负责 提交 ， 所 以 如 果 
当前 存在 保存 点 信息 便 不 是 最 外 层 事务 ， 不 做 保存 操作 ， 对 于 是 否 是 
新 事务 的 判断 也 是 基于 此 考虑 。 

如 果 程 序 流通 过 了 事务 的 层 层 把 关 ， 最 后 顺利 地 进入 了 提交 流 
程 ， 那 么 同样 ，Spring 会 将 事务 提交 的 操作 引导 至 底层 数据 库 连接 的 
API， 进 行事 务 提交 。 

protected void doCommit(DefaultTransactionStatus status) { 

DataSourceTransactionObject txObject = 
(DataSourceTransactionObject) status. 

getTransaction(); 

Connection con = 
txObject.getConnectionHolder().getConnection(); 

if (status.isDebug()) { 


logger.debug(""Committing JDBC transaction on Connection [" + 
con + "]"); 
} 
try { 
con.commit(); 
catch (SQLException ex) { 
throw new TransactionSystemException(" Could not commit 
JDBC transaction", ex); 


} 


第 11 章 “SpringMVC 


Spring 框架 提供 了 构建 Web 应 用 程序 的 全 功能 MVC 模 块 。 通 过 策 
略 接口 ，Spring 框 架 是 高 度 可 配置 的 ， 而 且 支 持 多 种 视图 技术 ， 例 如 
JavaServer Pages (JSP) 技术 、Velocity、Tiles、iText 和 POI。 Spring 
MVC 框 染 并 不 知道 使 用 的 视图 ， 所 以 不 会 强迫 您 只 使 用 JSP 技 术 。 
Spring MVC 分 离 了 控制 器 、 模 型 对 象 、 分 派 器 以 及 处 理 程 序 对 象 的 角 
色 ， 这 种 分 离 让 它们 更 容易 进行 定制 。 

Spring 的 MVC 是 基于 Servlet 功 能 实现 的 ， 通 过 实现 Servlet 接 口 的 
DispatcherServlet 来 封装 其 核心 功能 实现 ， 通 过 将 请 求 分 派 给 处 理 程 
序 ， 同 时 常 有 可 配置 的 处 理 程 序 映 射 、 视 图 解析 、 本 地 语言 、 主 题解 
析 以 及 上 载 文件 支持 。 默 认 的 处 理 程 序 是 非常 简单 的 Controller 接 
口 ， 只 有 一 个 方法 ModelAndView handleRequest(request, response)o 
Spring 提供 了 一 个 控制 器 层次 结构 ， 可 以 派生 子 类 。 如 果 应 用 程序 需 
要 处 理 用 户 输 入 表单 ， 那 么 可 以 继承 AbstractFormController。 如果 需 


要 把 多 页 输入 处 理 到 一 个 表单 ， 那 么 可 以 继承 
AbstractWizardFormControllero 

SpringMVC 或 者 其 他 比较 成 熟 的 MVC 框 架 而 言 ， 解 决 的 问题 无 外 
PA RIL RRs 

(1) 将 Web 页 面 的 请 求 传 给 服务 

(2) tot S ae 

(3) 返回 处 理 结果 数据 并 跳 转 至 响应 的 页 面 

我 们 首先 通过 一 个 简单 示例 来 快速 回顾 SpringMVC 的 使 用 。 


11.1 SpringMVC 快 速 体验 


(1) 配置 web.xml。 

一 个 Web 中 可 以 没有 web.xml 文 件 ， 也 就 是 说 ，web.xml 文 件 并 不 
是 Web 工 程 必须 的 。web.xml 文 件 用 来 初始 化 配置 信息 : 比如 Welcome 
页 面 、servlet、servlet-mapping、filter、listener、 启 动 加 载 级 别 等 。 但 
是 ，SpringMVC 的 实现 原理 是 通过 Servlet 拦 截 所 有 URL 来 达到 控制 的 
目的 ， 所 以 web.xml 的 配置 是 必须 的 。 

<?xml version="1.0" encoding="UTF-8"?> 

<web-app id="WebApp_ID" version="2.5" 
xmlIns="http://java.sun.com/xml/ns/javaee" 

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="http://java.sun. 

com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web- 
app 2 5.xsd"» 

<display-name>Springmvc</display-name> 
<!-- 使 用 ContextLoaderListener 配 置 时 ， 需 要 告诉 它 Spring 配 

置 文件 的 位 置 --> 


<context-param> 
<param-name>contextConfigLocation</param-name> 
<param-value>classpath:applicationContext.xml</param-value> 
</context-param> 
<!-- SpringMVC 的 前 端 控制 器 --> 
<!-- 当 DispatcherServlet 载 入 后 ， 它 将 从 一 个 XML 文件 中 载 入 
Spring 的 应 用 上 下 文 ， 该 XML 文件 的 名 
字 取 决 于 <servlet-name> --> 
<!-- 这 里 DispatcherServlet 将 试图 从 一 个 叫做 Springmvc- 
servlet.xml 的 文件 中 载 入 应 用 上 下 文 ， 其 
默认 位 于 WEB-INF 目 录 下 --> 
<servlet> 
<servlet-name>Springmvc</servlet-name> 
<servlet- 
class>org.Springframework.web.servlet.DispatcherServlet</servlet-class> 
<load-on-startup>1</load-on-startup> 
</servlet> 
<servlet-mapping> 
<servlet-name>Springmvc</servlet-name> 
<url-pattern>*.htm</url-pattern> 
</servlet-mapping> 
<!-- 配置 上 下 文 载 入 器 --> 
<!-- 上 下 文 载 入 器 载 入 除 DispatcherServlet 载 入 的 配置 文件 之 外 
的 其 它 上 下 文 配置 文件 --> 
<!-- 最 常用 的 上 下 文 载 入 器 是 一 个 Servlet 监 听 器 ， 其 名 称 为 
ContextLoaderListener --> 


<listener> 


«]istener- 
class>org.Springframework.web.context.ContextLoaderListener 
</listener-class> 
</listener> 
</web-app> 
Spring 的 MVC 之 所 以 必须 要 配置 web.xml， 其 实 最 关键 的 是 要 配置 
两 个 地 方 。 
contextConfigLocation: Spring 的 核心 就 是 配置 文件 ， 可 以 说 配置 
文件 是 Spring 中 必 不 可 少 的 东西 ， 而 这 个 参数 就 是 使 web 与 Spring 的 配 
置 文件 相 结合 的 一 个 关键 配置 。 
DispatcherServlet: 包含 了 SpringMVC 的 请 求 逻 辑 ，Spring 使 用 此 
类 拦截 Web 请 求 并 进行 相应 的 逻辑 处 理 。 
(2) 创建 Spring 配 置 文件 applicationContext.xml。 
<?xml version="1.0" encoding="UTF-8"?> 
«beans xmlns-"http://www.Springframework.org/schema/beans" 
xmins:xsi-"http://www.w3.0rg/2001/XMLSchema-instance" 


xmlns:tx="http://www.Springframework.org/schema/tx" 


xsi:schemaLocation="http://www.Springframework.org/schema/beans 
http://www. Springframework.org/schema/beans/Spring-beans- 
2.5.xsd 
http://www. Springframework.org/schema/tx 
http://www.Springframework.org/schema/tx/Spring-tx-2.5.xsd"> 
<bean id-"viewResolver" 
class="org.Springframework.web.servlet.view. Internal Resource 
ViewResolver"> 


<property name="prefix" value="/WEB-INF/jsp/"/> 


«property name="suffix" value=".jsp"/> 
</bean> 
</beans> 
InternalResourceViewResolver 是 一 个 辅助 Beaan， 会 在 
ModelAndView 返 回 的 视图 名 前 加 上 prefix 指定 的 前 缀 ， 再 在 最 后 加 上 
suffix 指定 的 后 缀 ， 例 如 : 由 于 XXController 返回 的 ModelAndView 中 
的 视图 名 是 testview， 故 该 视图 解析 器 将 在 /WEB-INF/jsp/testview.jsp 
处 查找 视图 。 
(3) 创建 model。 
模型 对 于 SpringMVC 来 说 并 不 是 必 不 可 少 ， 如 果 处 理 程序 非常 简 
单 ， 完 全 可 以 忽略 。 模 型 创建 主要 的 目的 就 是 承载 数据 ， 使 数据 传输 
更 加 方便 。 
public class User { 
private String username; 
private Integer age; 
public String getUsername() 1 
return username; 
j 
public void setUsername(String username) { 
this.username = username; 
j 
public Integer getAge() 1 
return age; 
j 
public void setAge(Integer age) 1 


this.age — age; 


j 
(4) 创建 controller。 
控制 器 用 于 处 理 Web 请 求 ， 每 个 控制 器 都 对 应 着 一 个 逻辑 处 理 。 
public class UserController extends AbstractController { 
@Override 
protected ModelAndView handleRequestInternal(HttpServletRequest 
arg0, HttpServletResponse 
arg1) throws Exception { 
List<User> userList = new ArrayList<User>(); 
User userA = new User(); 
User userB = new User(); 
userA.setUsername(" 张 三 "); 
userA.setAge(27); 
userB.setUsermame(" 李 四 "); 
userB.setAge(37); 
userList.add(userA ); 
userList.add(userB); 
return new ModelAndView("userlist", "users", userList); 
i 
j 
在 请 求 的 最 后 返回 了 ModelAndView 类 型 的 实例 。ModelAndView 
类 在 SpringMVC 中 占有 很 重要 的 地 位 ， 控制 器 执行 方法 都 必须 返回 一 
个 ModelAndView，ModelAndView 对 象 保存 了 视图 以 及 视图 显示 的 模 
型 数据 ， 例 如 其 中 的 参数 如 下 。 
第 一 个 参数 userlist: 视图 组 件 的 逻辑 名 称 。 这 里 视图 的 逻辑 名 称 
就 是 userlist， 视 图 解析 器 会 使 用 该 名 称 查找 实际 的 View 对 象 。 
第 二 个 参数 users: 传递 给 视图 的 ， 模 型 对 象 的 名 称 。 


第 三 个 参数 userList: 传递 给 视图 的 ， 模 型 对 象 的 值 。 
(5) 创建 视图 文件 userlist.jsp。 
<%@ page language="java" pageEncoding="UTF-8"%> 
<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core"%> 
<h2>This is SpringMVC demo page</h2> 
<c:forEach items="${users}" var="user"> 
<c:out value="${user.username}"/><br/> 
<c:out value="${user.age }"/><br/> 
</c:forEach> 
视图 文件 用 于 展现 请 求 处 理 结 果 ， 通 过 对 JSTL 的 支持 ， 可 以 很 方 
便 地 展现 在 控制 器 中 放 入 ModelAndView 中 的 处 理 结果 数据 。 
(6) 创建 Servlet 配 置 文件 Spring-servlet.xml。 
<?xml version="1.0" encoding="UTF-8"?> 
«beans xmlns-"http://www.Springframework.org/schema/beans" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xmlns:tx="http://www. Spring 


framework. org/schema/tx" 


xsi:schemaLocation="http://www.Springframework.org/schema/beans 
http://www. Springframework.org/schema/beans/Spring-beans-2.5.xsd 
http://www. Springframework.org/schema/tx 
http://www. Springframework.org/schema/tx/Spring-tx-2.5.xsd"> 
<bean id="simpleUrlMapping" 


class="org.Springframework.web.servlet.handler.SimpleUrlHandlerMappin 
g Ww > 
<property name="mappings"> 


<props> 
<prop key="/userlist.htm">userController</prop> 
</props> 
</property> 
</bean> 
<!-- 这 里 的 id="userController" 对 应 的 是 <bean 
id="simpleUrlMapping"> 中 的 <prop> 里 面 的 
Value --> 
<bean id="userController" class-"test.controller. UserController" /> 
</beans> 
为 SpringMVC 是 基于 Servlet 的 实现 ， 所 以 在 web 启动 的 时 候 ， 
服务 器 会 首先 尝试 加 载 对 应 于 Servlet 的 配置 文件 ， 而 为 了 让 项 目 更 加 
模块 化 ， 通 常 我 们 将 Web 部 分 的 配置 都 存放 于 此 配置 文件 中 。 
至 此 ， 已 经 完成 了 SpringMVC 的 搭建 ， 启 动 服 务 器 ， 输 入 网 址 
http://localhost:8080/Springmvc/userlist.htmo 
看 到 了 服务 器 返回 界面 ， 如 图 11-1 所 示 。 


Æ http://localhost:S080/springmvc/userlist.htm 
E 


This is SpringMVC demo page 
张 三 
27 


李 四 
37 


图 11-1 Spring MVC 快 速 体验 


11.2 ContextLoaderListener 


对 于 SpringMVC 功 能 实现 的 分 析 ， 我 们 首先 从 web.xml 开 始 ， 在 
web.xml 文 件 中 我 们 首先 配置 的 就 是 ContextLoaderListener， 那 么 它 所 
提供 的 功能 有 哪些 又 是 如 何 实现 的 呢 ? 

当 使 用 编程 方式 的 时 候 我 们 可 以 直接 将 Spring 配置 信息 作为 参数 
传 入 Spring 容器 中 ， 如 

ApplicationContext ac=new 
ClassPathXmlApplicationContext(“applicationContext.xml”); 

但 是 在 Web 下 ， 我 们 需要 更 多 的 是 与 Web 环境 相互 结合 ， 通 常 
的 办 法 是 将 路 径 以 context-param 的 方式 注册 并 使 用 
ContextLoaderListener 进 行 监听 读 取 。 

ContextLoaderListener 的 作用 就 是 启动 Web 容 器 时 ， 自 动 装 配 
ApplicationContext 的 配置 信息 。 因 为 它 实 现 了 ServletContextListener 这 
个 接口 ， 在 web.xml 配 置 这 个 监听 器 ， 启 动容 器 时 ， 就 会 默认 执行 它 实 
现 的 方法 ， 使 用 ServletContextListener 接 口 ， 开 发 者 能 够 在 为 客户 端 请 
求 提供 服务 之 前 向 ServletContext 中 添加 任意 的 对 象 。 这 个 对 象 在 
ServletContext 启 动 的 时 候 被 初始 化 ， 然 后 在 ServletContext 整 个 运行 期 
间 都 是 可 见 的 。 

一 个 Web 应 用 都 有 一 个 ServletContext 与 之 相关 联 。 
ServletContext 对 象 在 应 用 启动 时 被 创建 ， 在 应 用 关闭 的 时 候 被 销毁 。 
ServletContext 在 全 局 范围 内 有 效 ， 类 似 于 应 用 中 的 一 个 全 局 变量 。 

在 ServletContextListener 中 的 核心 逻辑 便 是 初始 化 
WebApplicationContext 实例 并 存放 至 ServletContext 中 。 


11.2.1 ServletContextListener 的 使 用 


正式 分 析 代 码 前 我 们 同样 还 是 首先 了 解 ServletContextListener 的 使 
用 。 
(1) 创建 自 定 义 ServletContextListenero 


首先 我 们 创建 ServletContextListener， 目 标 是 在 系统 启动 时 添加 自 
定义 的 属性 ， 以 便于 在 全 局 范围 内 可 以 随时 调用 。 系 统 启动 的 时 候 会 
调用 ServletContextListener 实现 类 的 contextInitialized 方 法 ， 所 以 需 
在 这 个 方法 中 实现 我 们 的 初始 化 逻辑 。 

public class MyDataContextListener implements 
ServletContextListener { 

private ServletContext context = null; 

public MyDataContextListener () { 

j 

// 该 方法 在 ServletContext 启 动 之 后 被 调用 ， 并 准备 好 处 理 客户 


public void contextInitialized(ServletContextEvent event) { 


this.context = event.getServletContext(); 
/通过 你 可 以 实现 自己 的 逻辑 并 将 结果 记录 在 属性 中 
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context = setAttribute(“myData”, 


} 
// 这 个 方法 在 ServletContext 将 要 关闭 的 时 候 调 用 


public void contextDestroyed(ServletContextEvent event){ 


this is myData"); 


this.context = null; 


} 
(2) 注册 监听 器 。 
在 web.xml 文 件 中 需要 注册 自 定义 的 监听 器 。 
<listener> 
com.test. My DataContextListener 


</listener> 


(3) 测试 。 


一 旦 Web 应 用 启动 的 时 候 ， 我 们 就 能 在 任意 的 Servlet 或 者 JSP 中 通 
过 下 面 的 方式 获取 我 们 初始 化 的 参数 ， 如 下 : 
String myData = (String) getServletContext().getAttribute(“myData”); 


11.2.2 Spring 中 的 ContextLoaderListener 


分 析 了 ServletContextListener 的 使 用 方式 后 再 来 分 析 Spring 中 的 
ContextLoaderListener 的 实现 就 容易 理解 的 多 ， 虽 然 
ContextLoaderListener 实 现 的 逻辑 要 复杂 的 多 ， 但 是 大 致 的 套路 还 是 万 
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ServletContext 启 动 之 后 会 调用 ServletContextListener 的 
contextInitialized 方 法 ， 那 么 ， 我 们 就 从 这 个 水 数 开始 进行 分 析 。 

public void contextInitialized(ServletContextEvent event) 1 

this.contextLoader = createContextLoader(); 
if (this.contextLoader == null) { 
this.contextLoader = this; 
} 
/初始 化 WebApplicationContext 


this.contextLoader.initWebA pplicationContext(event.getServletContext()); 

j 

这 里 涉及 了 一 个 常用 类 WebApplicationContext: 在 Web 应 用 中 ， 我 
们 会 用 到 WebApplication Context，WebApplicationContext 继 承 自 
ApplicationContext， 在 ApplicationContext 的 基础 上 又 追加 了 一 些 特定 
于 Web 的 操作 及 属性 ， 非 常 类 似 于 我 们 通过 编程 方式 使 用 Spring 时 使 
用 的 ClassPathXmlApplicationContext 类 提供 的 功能 。 继 续 跟 踪 代 码 : 

public WebApplicationContext 
initWebApplicationContext(ServletContext servletContext) { 


if 
(servletContext.getAttribute(WebApplicationContex.ROOT WEB. APPLI 
CATION . 
CONTEXT ATTRIBUTE) != null) 1 
/web.xml 中 存在 多 次 ContextLoader 定 义 
throw new IllegalStateException( 
"Cannot initialize context because there is already a root 
application context present - "+ 
web.xml!"); 
"check whether you have multiple ContextLoader* definitions in 
your 
} 
Log logger = LogFactory.getLog(ContextLoader.class); 
servletContext.log("Initializing Spring root 
WebApplicationContext"); 
if (logger.isInfoEnabled()) 1 
logger.info("Root WebApplicationContext: initialization 
started"); 
i 
long startTime = System.currentTimeMillis(); 
try { 
// Store context in local instance variable, to guarantee that 
// it is available on ServletContext shutdown. 
if (this.context == null) { 
/初始 化 context 


this.context = createWebApplicationContext(servletContext); 


if (this.context instanceof ConfigurableWebApplicationContext) 


configureAndRefreshWebA pplicationContext((ConfigurableWebA pplicatio 
n 
Context)this.context, servletContext); 
j 
/记录 在 servletContext 中 


servletContext.setAttribute(WebApplicationContex.ROOT WEB. APPLIC 
ATION_ 
CONTEXT_ATTRIBUTE, this.context); 
ClassLoader ccl = 
Thread.currentThread().getContextClassLoader(); 
if (ccl == ContextLoader.class.getClassLoader()) { 
currentContext = this.context; 
} 
else if (ccl != null) { 
currentContextPerThread.put(ccl, this.context); 
} 
if (logger.isDebugEnabled()) { 
logger.debug( Published root WebApplicationContext as 
ServletContext 


attribute with name [" + 


WebApplicationContex.ROOT WEB APPLICATION CONTEXT ATTR 
IBUTE 


+ "]"); 
} 
if (logger.isInfoEnabled()) { 
long elapsedTime = System.currentTimeMillis() - start Time; 
logger.info("Root WebApplicationContext: initialization 
completed in 
" + elapsedTime + " ms"); 
} 
return this.context; 
} 
catch (RuntimeException ex) { 


logger.error("Context initialization failed", ex); 


servletContext.setAttribute(WebApplicationContext.ROOT_WEB_APPLIC 
ATION_ 
CONTEXT_ATTRIBUTE, ex); 
throw ex; 
} 
catch (Error err) { 


logger.error("Context initialization failed", err); 


servletContext.setAttribute(WebApplicationContext.ROOT_WEB_APPLIC 
ATION_ 
CONTEXT_ATTRIBUTE, err); 


throw err; 


initWebApplicationContext 图 数 主要 是 体现 了 创建 
WebApplicationContext 实例 的 一 个 功能 架构 ， 从 函数 中 我 们 看 到 了 初 
始 化 的 大 致 步骤 。 

(1) WebApplicationContext 存 在 性 的 验证 。 

在 配置 中 只 人 允许 声明 一 次 ServletContextListener， 多 次 声明 会 扰乱 
Spring 的 执行 逻辑 ， 所 以 这 里 首先 做 的 就 是 对 此 验证 ， 在 Spring 中 如 
果 创 建 WebA pplicationContext 实例 会 记录 在 ServletContext 中 以 方便 全 
局 调用 ， 而 使 用 的 key 就 是 
WebApplicationContex.ROOT WEB APPLICATION CONTEXT ATTR 
IBUTE， 所 以 验证 的 方式 就 是 查看 ServletContext 实 例 中 是 否 有 对 应 key 
的 属性 。 

(2) 创建 WebApplicationContext 实 例 。 

如 果 通 过 验证 ， 则 Spring 将 创建 WebApplicationContext 实例 的 工 
作 委 托 给 了 create WebApplicationContextEK| 2X. 

protected WebApplicationContext 
createWebApplicationContext(ServletContext sc) { 

Class<?> contextClass = determineContextClass(sc); 
if 
(!ConfigurableWebApplicationContext.class.isAssignableFrom(contextClas 
s)) t 
throw new ApplicationContextException(" Custom context class 
[" + 
contextClass.getName() + 
"] is not of type [" + 
ConfigurableWebApplicationContext.class.getName() 
+"); 


ConfigurableWebApplicationContext wac = 
(ConfigurableWebA pplicationContext) BeanUtils.instantiateClass 
(contextClass); 
return wac; 
j 
protected Class<?> determineContextClass(ServletContext 
servletContext) { 
//CONTEXT CLASS PARAM = "contextClass"; 
String contextClassName = 
servletContext.getInitParameter(CONTEXT CLASS PARAM); 
if (contextClassName !- null) { 
try { 
return ClassUtils.forName(contextClassName, 
ClassUtils.getDefaultClass 
Loader()); 
j 
catch (ClassNotFoundException ex) 1 
throw new ApplicationContextException( 


"Failed to load custom context class [" + contextClassName + 


"J", ex); 
j 
j 
else { 
contextClassName = 


defaultStrategies.getProperty(WebApplicationContext. 
class.getName()); 
try { 


return ClassUtils.forName(contextClassName, 
ContextLoader.class. 
getClassLoader()); 
j 
catch (ClassNotFoundException ex) 1 
throw new ApplicationContextException( 


"Failed to load default context class [" + contextClassName 


+ "|", ex) 
} 
} 
j 
其 中 ， 在 ContextLoader 类 中 有 这 样 的 静态 代码 块 : 
static { 


// Load default strategy implementations from properties file. 
// This is currently strictly internal and not meant to be customized 
// by application developers. 
try { 
//DEFAULT STRATEGIES PATH = 
"ContextLoader.properties" 
ClassPathResource resource = new 
ClassPathResource(DEFAULT_STRATEGIES_PATH, 
ContextLoader.class); 
defaultStrategies = 
PropertiesLoaderUtils.loadProperties(resource); 
} 
catch (IOException ex) { 


throw new IllegalStateException(" Could not load 
"ContextLoader.properties": 


"+ ex.getMessage()); 


j 
根据 以 上 静态 代码 块 的 内 容 ， 我 们 推断 在 当前 类 ContextLoader [Al 
样 目 录 下 必定 会 存在 属性 文件 ContextLoader.properties， 查 看 后 果然 存 
在 ， 内 容 如 下 : 
org.Springframework.web.context. WebApplicationContext-org.Spring 
framework.web.context. 
support. XmlWebA pplicationContext 
综合 以 上 代码 分 析 ， 在 初始 化 的 过 程 中 ， 程 序 首 先 会 读 取 
ContextLoader 类 的 同 目录 下 的 属性 文件 ContextLoader.properties， 并 根 
据 其 中 的 配置 提取 将 要 实现 WebApplicationContext 接 口 的 实现 类 ， 并 
根据 这 个 实现 类 通过 反射 的 方式 进行 实例 的 创建 。 
(3) 将 实例 记录 在 servletContext 中 。 
(4) 映射 当前 的 类 加 载 器 与 创建 的 实例 到 全 局 变量 


currentContextPerThread o 
11.3 DispatcherServlet 


在 Spring 中 ，ContextLoaderListener 只 是 辅助 功能 ， 用 于 创建 
WebApplicationContext 类 型 实例 ， 而 真正 的 逻辑 实现 其 实 是 在 
DispatcherServlet 中 进行 的 ，DispatcherServlet 是 实现 servlet 接 口 的 实现 


类 。 


servlet 是 一 个 Java 编写 的 程序 ， 此 程序 是 基于 HTTP 协议 的 ,在 
服务 器 端 运行 的 〈 如 Tomcat) ， 是 按照 servlet 规 范 编写 的 一 个 Java 类 。 


主要 是 处 理 客户 端的 请 求 并 将 其 结果 发 送 到 客户 端 。servlet 的 生命 周 
期 是 由 servlet 的 容器 来 控制 的 ， 它 可 以 分 为 3 个 阶段 : 初始 化 、 运 行 和 
销毁 。 
(1) 初始 化 阶段 。 
servlet 容 器 加 载 servlet 类 ， 把 servlet 类 的 .class 文 件 中 的 数据 读 到 内 
FA, 
servlet 容 器 创建 一 个 ServletConfig 对 象 。ServletConfig 对 象 包 含 了 
servlet 的 初始 化 配置 信息 。 
servlet 容 器 创建 一 个 servlet 对 象 。 
servlet 容 器 调用 servlet 对 象 的 init 方 法 进行 初始 化 。 
(2) 运行 阶段 。 
当 servlet 容器 接收 到 一 个 请 求 时 ，servlet 容器 会 针对 这 个 请 求 创 
建 servletRequest 和 servletResponse 对 象 ， 然 后 调用 service 方 法 。 并 把 
这 两 个 参数 传递 给 service 方 法 。service 方 法 通过 servletRequest 对 象 获 
得 请 求 的 信息 。 并 处 理 该 请 求 。 再 通过 servletResponse 对 象 生 成 这 个 
请 求 的 响应 结果 。 然 后 销毁 servletRequest 和 servletResponse WR. HK 
们 不 管 这 个 请 求 是 post 提 交 的 还 是 get 提 交 的 ， 最 终 这 个 请 求 都 会 由 
service 方 法 来 处 理 。 
(3) 销毁 阶段 。 
当 Web 应 用 被 终止 时 ，servlet 容 器 会 先 调 用 servlet 对 象 的 destrory 方 
法 ， 然 后 再 销毁 servlet 对 象 ， 同 时 也 会 销毁 与 servlet 对 象 相 关联 的 
servletConfig 对 象 。 我 们 可 以 在 destroy 方 法 的 实现 中 ， 释 放 servlet 所 占 
用 的 资源 ， 如 关闭 数据 库 连 接 ， 关 闭 文 件 输入 输出 流 等 。 
servlet 的 框架 是 由 两 个 Java 包 组 成 : javax.servlet 和 
javax.servlet.http。 在 javax.servlet 包 中 定义 了 所 有 的 servlet 类 都 必须 实 
现 或 扩展 的 通用 接口 和 和 类， 在 javax.servlet.http 包 中 定义 了 采用 HTTP 通 
信 协 议 的 HttpServlet 类 。 


servlet 被 设计 成 请 求 驱动 ，servlet 的 请 求 可 能 包含 多 个 数据 项 ， 
34 Web 容器 接收 到 某 个 servlet 请 求 时 ，servlet 把 请 求 封 装 成 一 个 
HttpServletRequest 对 象 ， 然 后 把 对 象 传 给 servlet 的 对 应 的 服务 方法 。 

HTTP 的 请 求 方 式 包 括 delete、get、options、post、put 和 trace， 在 
HttpServlet 类 中 分 别提 供 了 相应 的 服务 方法 ， 它 们 是 doDelete()、 
doGet()、doOptions()、doPost()、doPut() 和 doTrace()。 


11.3.1 servlet 的 使 用 
我 们 同样 还 是 以 最 简单 的 servlet 来 快速 体验 其 用 法 。 
(1) 建立 servlet。 
public class MyServlet extends HttpServlet{ 
public void initQ){ 
System.out.printIn("this is init method"); 
} 
public void doGet(HttpServletRequest request, 
HttpServletResponse response) { 
handleLogic(request,response); 
} 
public void doPost(HttpServletRequest request, 
HttpServletResponse response) { 
handleLogic(request,response); 
} 
private void handleLogic(HttpServletRequest request, 
HttpServletResponse response) { 
System.out.printin("handle myLogic"); 
ServletContext sc = getServletContext(); 


RequestDispatcher rd = null; 


rd = sc.getRequestDispatcher("/index.jsp"); /定向 的 页 面 
try { 

rd.forward(request, response); 
} catch (ServletException | IOException e) 1 

e.printStack Trace(); 


j 
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理 ，init 方 法 保证 在 在 servlet 加 载 的 时 候 能 做 一 些 逻 辑 操作 ， 而 
HttpServlet 类 则 会 帮助 我 们 根据 方法 类 型 的 不 同 而 将 逻辑 引入 不 同 的 
图 数 。 在 子 类 中 我 们 只 需要 重 写 对 应 的 函数 逻辑 便 可 ， 如 以 上 代码 重 
写 了 doGet 和 doPost 方 法 并 将 逻辑 处 理 部 分 引导 至 handleLogic 函 数 中 ， 
最 后 ， 又 将 页 面 跳 转 至 index.jsp。 
(2) 添加 配置 。 
为 了 使 servlet 能 够 正常 使 用 ， 需 要 在 web.xml 文 件 中 添加 以 下 配 
B. 
<servlet> 
<servlet-name>myservlet</servlet-name> 
<servlet-class>test.servlet.MyServlet</servlet-class> 
<load-on-startup>1</load-on-startup> 
</servlet> 
<servlet-mapping> 
<servlet-name>myservlet</servlet-name> 
<url-pattern>*.htm</url-pattern> 


</servlet-mapping> 


配置 后 便 可 以 根据 对 应 的 配置 访问 响应 的 路 径 了 。 


11.3.2 DispatcherServlet 的 初始 化 


通过 上 面 的 实例 我 们 了 解 到 ， 在 servlet 初 始 化 阶段 会 调用 其 init 方 
法 ， 所 以 我 们 首先 要 查看 在 DispatcherServlet 中 是 否 重 写 了 init 方 法 。 我 
们 在 其 父 类 HttpServletBean 中 找到 了 该 方法 。 
public final void init() throws ServletException { 
if (logger.isDebugEnabled()) 1 
logger.debug("Initializing servlet ™ + getServletName() + ””); 
} 
try { 
// 解 析 init-param 并 封装 只 pvs 中 
PropertyValues pvs = new 
ServletConfigPropertyValues(getServletConfig(), 
this.requiredProperties); 
// 将 当前 的 这 个 Servlet 类 转化 为 一 个 BeanWrapper, 从 而 能 够 以 
Spring 的 方式 来 对 init-param 
的 值 进行 注 
BeanWrapper bw = 
PropertyAccessorFactory.forBeanPropertyAccess(this); 
ResourceLoader resourceLoader = new 
ServletContextResourceLoader 
(getServletContext()); 
/注册 自 定义 属性 编辑 器 ， 一 旦 遇 到 Resource 类 型 的 属性 将 会 
使 用 ResourceEditor 进 行 解析 
bw.registerCustomEditor(Resource.class, new 
ResourceEditor(resourceLoader, 


this.environment)); 


， 留 给 子 类 覆盖 
; 
/属性 注入 
bw.setProperty Values(pvs, true); 
j 
catch (BeansException ex) 1 
logger.error("Failed to set bean properties on servlet " + 
getServletName() 
+1", ex); 
throw ex; 
j 
// 留 给 子 类 扩展 
initServletBean(); 
if (logger.isDebugEnabled()) { 
logger.debug(" Servlet "" + getServletName() + " configured 
successfully"); 
j 

} 

DipatcherServlet 的 初始 化 过 程 主要 是 通过 将 当前 的 servlet 类 型 实例 
转换 为 BeanWrapper 类 型 实例 ， 以 便 使 用 Spring 中 提供 的 注入 功能 进行 
对 应 属性 的 注入 。 这 些 属性 如 contextAttribute、contextClass、 
nameSpace、 contextConfigLocation 等 ， 都 可 以 在 web.xml 文 件 中 以 初始 
化 参数 的 方式 配置 在 servlet 的 声明 中 。DispatcherServlet 继 承 自 
FrameworkServlet，FrameworkServlet 类 上 包含 对 应 的 同名 属性 ， 
Spring 会 保证 这 些 参 数 被 注入 到 对 应 的 值 中 。 属 性 注入 主要 包含 以 下 
几 个 步 又 。 

1. 封装 及 验证 初始 化 参数 


ServletConfigPropertyValues 除 了 封装 属性 外 还 有 对 属性 验证 的 功 
能 。 
public ServletConfigProperty Values(ServletConfig config, 
Set<String> requiredProperties) 
throws ServletException 1 
Set<String> missingProps = (requiredProperties != null && 
!requiredProperties. 
isEmpty()) ? 
new HashSet<String>(requiredProperties) : null; 
Enumeration en - config.getInitParameterNames(); 
while (en.hasMoreElements()) 1 
String property = (String) en.nextElement(); 
Object value 7 config.getInitParameter(property); 
addProperty Value(new Property Value(property, value)); 
if (missingProps !- null) 1 


missingProps.remove(property); 


} 
// Fail if we are still missing properties. 
if (missingProps != null && missingProps.size() > 0) { 
throw new ServletException( 
"Initialization from ServletConfig for servlet ™ + 
config.getServlet 
Name() + 
"failed; the following required properties were missing: " + 


StringUtils.collectionToDelimitedString(missingProps, ", ")); 


} 

从 代码 中 得 知 ， 封 和 属性 主要 是 对 初始 化 的 参数 进行 封 季 ， 也 就 
是 servlet 中 配置 的 <init-param> 中 配置 的 封装 。 当 然 ， 用 户 可 以 通过 对 
requiredProperties 参 数 的 初始 化 来 强制 验证 某 些 属性 的 必要 性 ， 这 样 ， 
在 属性 封装 的 过 程 中 ， 一旦 检测 到 requiredProperties 中 的 属性 没有 指定 
初始 值 ， 就 会 抛 出 异 音 。 

2. 将 当前 servlet 实 例 转化 成 BeanWrapper 实 例 

PropertyAccessorFactory.forBeanPropertyAccess 是 Spring 中 提供 的 工 
具 方 法 ， 主 要 用 于 将 指定 实例 转化 为 Spring 中 可 以 处 理 的 BeanWrapper 
类 型 的 实例 。 

3。 注 册 相 对 于 Resource 的 属性 编辑 器 

属性 编辑 器 ， 我 们 在 上 文中 已 经 介绍 并 且 分 析 过 其 原理 ， 这 里 使 
用 属性 编辑 器 的 目的 是 在 对 当前 实例 ( DispatcherServlet ) 属性 注入 
过 程 中 一 旦 遇 到 Resource 类 型 的 属性 就 会 使 用 ResourceEditor 去 解析 。 

4. 属性 注入 

BeanWrapper 为 Spring 中 的 方法 ， 支 持 Spring 的 自动 注入 。 其 实 我 
们 最 单 用 的 属性 注入 无 非 是 contextAttribute、 contextClass, 
nameSpace、contextConfigLocation 等 属性 。 

5。servletBean 的 初始 化 

在 ContextLoaderListener 加 载 的 时 候 已 经 创建 了 
WebApplicationContext 实 例 ， 而 在 这 个 函数 中 最 重要 的 就 是 对 这 个 实 
例 进行 进一步 的 补充 初始 化 。 

继续 查看 initServletBean0。 父 类 FrameworkServlet 履 盖 了 
HttpServletBean 中 的 initServlet Bean Zik, WF: 

protected final void initServletBean() throws ServletException { 

getServletContext().log("Initializing Spring FrameworkServlet "' + 


getServlet 


Name() 十 sae 
if (this. logger.isInfoEnabled()) { 


this.logger.info("FrameworkServlet " + getServletName() + ”: 


initialization 
started"); 
} 
long startTime = System.currentTimeMillis(); 
try { 
this.webApplicationContext = initWebApplicationContext(); 
INU ALT RE me 
initFrameworkServlet(); 
} 


catch (ServletException ex) { 
this.logger.error("Context initialization failed", ex); 
throw ex; 
} 
catch (RuntimeException ex) { 
this.logger.error("Context initialization failed", ex); 
throw ex; 
} 
if (this. logger.isInfoEnabled()) { 
long elapsedTime = System.currentTimeMillis() - startTime; 
this.logger.info("FrameworkServlet ' + getServletName() + ”: 
initialization completed in " + 


elapsedTime + " ms"); 


上 面 的 函数 设计 了 计时 器 来 统计 初始 化 的 执行 时 间 ， 而 且 提 供 了 
一 个 扩展 方法 initFrameworkServlet() 用 于 子 类 的 覆盖 操作 ， 而 作为 关键 
的 初始 化 逻辑 实现 委托 给 了 initWebApplicationContext()o 


11.3.3 WebApplicationContext 的 初始 化 


initWebApplicationContext 水 数 的 主要 工作 就 是 创建 或 刷新 
WebApplicationContext 实例 并 对 servlet 功 能 所 使 用 的 变量 进行 初始 
化 。 
Protected WebApplicationContext initWebApplicationContext() { 
WebApplicationContext rootContext = 


WebApplicationContextUtils.getWebApplicationContext(getServletContext 
0); 
WebApplicationContext wac = null; 
if (this.webApplicationContext != null) { 
//contextSz DTE 438 RRRA 
wac = this.webApplicationContext; 
if (wac instanceof ConfigurableWebApplicationContext) 1 
ConfigurableWebApplicationContext cwac = 
(ConfigurableWebA pplication 
Context) wac; 
if (!cwac.isActive()) 1 
if (cwac.getParent() == null) 1 
cwac.setParent(rootContext); 
} 
/刷新 上 下 文 环 境 
configureAndRefreshWebApplicationContext(cwac); 


if (wac == null) { 
/根据 contextAttribute 属 性 加 载 WebApplicationContext 
wac = findWebApplicationContext(); 
i 
if (wac == null) { 
// No context instance is defined for this servlet -> create a local 
one 
wac = createWebApplicationContext(rootContext); 
} 
if (!this.refreshEventReceived) { 
// Either the context is not a ConfigurableApplicationContext 
with refresh 
// support or the context injected at construction time had already 
been 
// refreshed -> trigger initial onRefresh manually here. 
onRefresh(wac); 
} 
if (this.publishContext) { 
// Publish the context as a servlet context attribute. 
String attrName = getServletContextAttributeName(); 
getServletContext().setAttribute(attrName, wac); 
if (this. logger.isDebugEnabled()) { 
this.logger.debug(" Published WebApplicationContext of 


servlet "+ 


getServletName() + 


"' as ServletContext attribute with name [" + attrName + "]"); 


} 
return wac; 

} 

对 于 本 函数 中 的 初始 化 主要 包含 几 个 部 分 。 

1. 寻找 或 创建 对 应 的 webApplicationContext 实 例 

WebApplicationContext 的 寻找 及 创建 包括 以 下 几 个 步骤 。 

(1) 通过 构造 函数 的 注入 进行 初始 化 。 

当 进 入 initWebApplicationContextEK|Z [E388 Fl fr 
this.webApplicationContext != null 后 ， 便 可 以 确定 
this.webApplicationContext 是 否 是 通过 构造 水 数 来 初始 化 的 。 可 是 有 读 
者 可 能 会 有 疑问 ， 在 initServletBean 疗 | 数 中 明明 是 把 创建 好 的 实例 记录 
在 了 this.webApplicationContext 中 : 

this.webApplicationContext= initWebApplicationContext(); 

何以 判定 这 个 参数 是 通过 构造 水 数 初 始 化 ， 而 不 是 通过 上 一 次 的 
国 数 返回 值 初始 化 呢 ? 如 果 存 在 这 个 问题 ， 那 么 就 是 读者 忽略 一 个 问 
题 了 : 在 Web 中 包含 SpringWeb 的 核心 逻辑 的 DispatcherServlet 只 可 
以 被 声明 为 一 次 ， 在 Spring 中 已 经 存在 验证 ， 所 以 这 就 确保 了 如 果 
this.webApplicationContext != null， 则 可 以 直接 判定 
this.webApplicationContext 已 经 通过 构造 国 数 初始 化 。 

(2) 通过 contextAttribute 进 行 初始 化 。 

通过 在 web.xml 文 件 中 配置 的 servlet 参 数 contextAttribute 来 查找 
ServletContext 中 对 应 的 属性 ， 默 认为 
WebApplicationContext.class.getName() + ".ROOT"， 也 就 是 在 
ContextLoaderListener 加 载 时 会 创建 WebApplicationContext 实 例 ， 并 将 


52 sl LL WebA pplicationContext.class.getName() + ".ROOT"Y key 放 入 
ServletContext 中 ， 当 然 读者 可 以 重 写 初始 化 逻辑 使 用 自己 创建 的 
WebApplicationContext， 并 在 servlet 的 配置 中 通过 初始 化 参数 
contextAttribute 指 定 keyo 
protected WebApplicationContext findWebApplicationContext() 1 
String attrName = getContextAttribute(); 
if (attrName == null) { 
return null; 
WebApplicationContext wac = 


attrName); 


WebApplicationContextUtils.getWebA pplicationContext(getServletContext 
(), 
if (wac == null) { 
throw new IllegalStateException("No WebApplicationContext 
found: initializer 
not registered?"); 
return wac; 
} 
(3) 重新 创建 WebApplicationContext 实 例 。 
如 果 通 过 以 上 两 种 方式 并 没有 找到 任何 突破 ， 那 就 没 办 法 了 ， 只 
能 在 这 里 重新 创建 新 的 实例 了 。 
protected WebA pplicationContext 
createWebA pplicationContext( WebA pplicationContext parent) 1 
return createWebA pplicationContext((ApplicationContext) parent); 


j 
protected WebA pplicationContext 
createWebA pplicationContext(ApplicationContext parent) 1 
/获取 servlet 的 初始 化 参数 contextClass, 如 果 没 有 配置 默认 为 
XmIWebA pplicationContext.class 
Class<?> contextClass = getContextClass(); 
if (this.logger.isDebugEnabled()) 1 
this.logger.debug(" Servlet with name "' + getServletName() + 
"will try to create custom WebApplicationContext context of 
class '" + 
contextClass.getName() + ""  ", using parent context [" + 
parent + "]"); 
j 
if 
(!ConfigurableWebApplicationContext.class.isAssignableFrom(contextClas 
s)) t 
throw new ApplicationContextException( 
"Fatal initialization error in servlet with name " + 
getServletName() + 
": custom WebApplicationContext class [" + 
contextClass.getName() + 
"] is not of type ConfigurableWebApplicationContext"); 
} 
/通过 反射 方式 实例 化 contextClass 
ConfigurableWebApplicationContext wac = 
(ConfigurableWebApplicationContext) BeanUtils.instantiateClass 


(contextClass); 


/parent 为 在 ContextLoaderListener 中 创建 的 实例 
/在 ContextLoaderListener 加 载 的 时 候 初 始 化 的 
WebApplicationContext 类 型 实例 
wac.setParent(parent); 
/获取 contextConfigLocation 属 性 ， 配 置 在 servlet 初 始 化 参数 中 
wac.setConfigLocation(getContextConfigLocation()); 
/初始 化 Spring 环境 包括 加 载 配置 文件 等 
configureAndRefreshWebA pplicationContext(wac); 
return wac; 
j 
2. configureAndRefreshWebApplicationContext 
JEJE SW His HEARS PIE, Be T AUS 
configureAndRefreshWeb Application Context 方 法 来 对 已 经 创建 的 
WebApplicationContext 实 例 进 行 配置 及 刷新 ， 那 么 这 个 步骤 又 做 了 哪 
些 工 作 呢 ? 
protected void 
configureAndRefreshWebApplicationContext(ConfigurableWebApplication 
Context wac, ServletContext sc) { 
if (ObjectUtils.identityToString(wac).equals(wac.getId())) { 
// The application context id is still set to its original default 
value 
// -> assign a more useful id based on available information 
String idParam = sc.getInitParameter(CONTEXT ID PARAM); 
if (idParam != null) { 
wac.setId(idParam); 
j 


else { 


// Generate default id... 
if (sc.getMajorVersion() == 2 && sc.getMinorVersion() « 5) 1 


// Servlet <= 2.4: resort to name specified in web.xml, if 


any. 


wac.setId(ConfigurableWebApplicationContext. APPLICATION - 
CONTEXT 
ID PREFIX + 
ObjectUtils.getDisplayString(sc.getServletContextName())); 
} 


else { 


wac.setId(ConfigurableWebApplicationContext. APPLICATION CONTEX 
d 


ID PREFIX + 
ObjectUtils.getDisplayString(sc.getContextPath())); 


} 


// Determine parent for root web application context, if any. 
ApplicationContext parent = loadParentContext(sc); 
wac.setParent(parent); 
wac.setServletContext(sc); 
String initParameter = 
sc.getInitParameter(CONFIG LOCATION PARAM); 
if (initParameter != null) 1 


wac.setConfigLocation(initParameter); 


j 
customizeContext(sc, wac); 
/加 载 配置 文件 及 整合 parent 到 wac 
wac.refresh(); 
j 
无 论调 用 方式 如 何 变化 ， 只 要 是 使 用 AlicationContext 所 提供 的 功 
能 最 后 都 免不了 使 用 公共 父 类 AbstractApplicationContext 提 供 的 
refresh() 进 行 配 置 文件 加 载 。 
3. 刷新 
onRefresh 是 FrameworkServlet 类 中 提供 的 模板 方法 ， 在 其 子 类 
DispatcherServlet 中 进行 了 重 写 ， 主 要 用 于 刷新 Spring 在 Web 功 能 实现 
中 所 必须 使 用 的 全 局 变量 。 下 面 我 们 会 介绍 它们 的 初始 化 过 程 以 及 使 
用 场景 ， 而 至 于 具体 的 使 用 细节 会 在 稍 后 的 章节 中 再 做 详细 介绍 。 
protected void onRefresh(ApplicationContext context) { 
initStrategies(context); 
j 
protected void initStrategies(ApplicationContext context) 1 
//(1) 初 始 化 MultipartResolver 
initMultipartResolver(context); 
//(2) 初 始 化 LocaleResolver 
initLocaleResolver(context); 
//(3) 初 始 化 ThemeResolver 
initThemeResolver(context); 
//(4) 初 始 化 HandlerMappings 
initHandlerMappings(context); 
//(5) 初 始 化 HandlerAdapters 
initHandlerA dapters(context); 


/(6) 初 始 化 HandlerExceptionResolvers 
initHandlerExceptionResolvers(context); 
//(7) 初 始 化 RequestToViewNameTranslator 
initRequestTo ViewNameTranslator(context); 
/(8) 初 始 化 ViewResolvers 
initViewResolvers(context); 
/(9) 初 始 化 FlashMapManager 
initFlashMapManager(context); 
j 
(1) 初始 化 MultipartResolver。 

在 Spring 中 ，MnultipartResolver 主 要 用 来 处 理 文件 上 传 。 默 认 情 况 
下 ，Spring 是 没有 multipart 处 理 的 ， 因 为 一 些 开发 者 想 要 自己 处 理 它 
们 。 如 果 想 使 用 Spring 的 multipart， 则 需要 在 Web 应 用 的 上 下 文中 添 
加 multipart 解 析 器 。 这 样 ， 每 个 请 求 就 会 被 检查 是 否 包 含 multipart。 然 
而 ， 如 果 请 求 中 包含 multipart， 那 么 上 下 文中 定义 的 MultipartResolver 
就 会 解析 它 ， 这 样 请 求 中 的 multipart 属 性 就 会 象 其 他 属性 一 样 被 处 
理 。 常 用 配置 如 下 : 

<bean id="multipartResolver" 
class="org.Springframework.web.multipart.commons. Commons 

MultipartResolver"> 

<!-- 该 属性 用 来 配置 可 上 传 文件 的 最 大 byte 数 --> 

<property name="maximumFileSize"><value>100000</value> 
</property> 

</bean> 

49%, CommonsMultipartResolver 还 提供 了 其 他 功能 用 于 帮助 用 
户 完成 上 传 功能 ， 有 兴趣 的 读者 可 以 进一步 查看 。 


那么 MultipartResolver 就 是 在 initMultipartResolver 中 被 加 入 到 
DispatcherServlet 中 的 。 
private void initMultipartResolver(ApplicationContext context) { 
try { 
this.multipartResolver = 
context.getBean(MULTIPART RESOLVER, BEAN NAME, 
MultipartResolver.class); 
if (logger.isDebugEnabled()) 1 
logger.debug( Using MultipartResolver [" + 
this.multipartResolver + "]"); 
} 
} 
catch (NoSuchBeanDefinitionException ex) { 
// Default is no multipart resolver. 
this.multipartResolver = null; 
if (logger.isDebugEnabled()) { 
logger.debug( Unable to locate MultipartResolver with name 
"Go 
MULTIPART RESOLVER, BEAN NAME + 


"no multipart request handling provided"); 


} 

因为 之 前 的 步骤 已 经 完成 了 "DRE 配置 文件 的 解析 ， 所 以 在 这 

只 要 在 配置 文件 注册 过 都 可 以 通过 ApplicationContext 提供 的 
getBean 方法 来 直接 获取 对 应 bean ， 进 而 初始 化 MultipartResolver 中 的 


multipartResolver 变 量 。 


(2) 初始 化 LocaleResolver。 

在 Spring 的 国际 化 配置 中 一 共有 3 种 使 用 方式 。 

基于 URL 人 参数 的 配置 。 

通过 URL 参 数 来 控制 国际 化 ， 比 如 你 在 页 面 上 加 一 句 <a href="? 
locale=zh_CN"> 简 体 中文 </a> 来 控制 项 目 中 使 用 的 国际 化 参数 。 而 提 
供 这 个 功能 的 就 是 AcceptHeaderLocaleResolver， 默 认 的 参数 名 为 
locale， 注 意 大 小 写 。 里 面 放 的 就 是 你 的 提交 参数 ， 比 如 en_US、 
zh_CN 之 类 的 ， 具 体 配 置 如 下 ，; 

<bean id="localeResolver" 
class="org.Springframework.web.servlet.i18n. AcceptHeader 

LocaleResolver"/> 

基于 session 的 配置 。 

它 通过 检验 用 户 会 话 中 预 置 的 属性 来 解析 区 域 。 最 常用 的 是 根据 
用 户 本 次 会 话 过 程 中 的 语言 设 定 决定 语言 种 类 (例如 ， 用 户 登 录 时 选 
择 语言 种 类 ， 则 此 次 登录 周期 内 统一 使 用 此 语言 设 定 ) ， 如 果 该 会 话 
属性 不 存在 ， 它 会 根据 accept-language HITP 头 部 确定 默认 区 域 。 

<bean id="localeResolver" 
class="org.Springframework.web.servlet.i18n.SessionLocaleResolver"/> 

基于 Cookie 的 国际 化 配置 。 

CookieLocaleResolver 用 于 通过 浏览 器 的 cookie 设 置 取 得 Locale 对 
象 。 这 种 策略 在 应 用 程序 不 支持 会 话 或 者 状态 必须 保存 在 客户 端 时 有 
用 ， 配 置 如 下 : 

<bean id="localeResolver" 
class="org.Springframework.web.servlet.i18n.CookieLocaleResolver"/> 

这 3 种 方式 都 可 以 解决 国际 化 的 问题 ， 但 是 ， 对 于 LocalResolver 
的 使 用 基础 是 在 DispatcherServlet 中 的 初始 化 。 


private void initLocaleResolver(ApplicationContext context) { 


try { 
this.localeResolver = 
context.getBean(LOCALE RESOLVER. BEAN NAME, Localeffü 
Ei Resolver.class); 
if (logger.isDebugEnabled()) { 
logger.debug(" Using LocaleResolver [" + this.localeResolver 


十 "J"; 


catch (NoSuchBeanDefinitionException ex) { 
// We need to use the default. 
this.localeResolver = getDefaultStrategy(context, 
LocaleResolver.class); 
if (logger.isDebugEnabled()) { 
logger.debug(" Unable to locate LocaleResolver with name " + 
LOCALE RESOLVER BEAN NAME + 


"': using default [" + this.localeResolver + "J"; 


} 
提取 配置 文件 中 设置 的 LocaleResolver 来 初始 化 DispatcherServlet 中 
的 localeResolver 属 性 。 
(3) 初始 化 ThemeResolver。 
在 Web 开 发 中 经 常会 遇 到 通过 主题 Theme 来 控制 网 页 风格 ， 这 将 
进一步 改善 用 户 体验 。 简 单 地 说 ， 一 个 主题 就 是 一 组 静态 资源 (比如 
样式 表 和 图 片 ) ， 它 们 可 以 影响 应 用 程序 的 视觉 效果 。Spring 中 的 主 


题 功 能 和 国际 化 功能 非常 类 似 。 构 成 Spring 主题 功能 主要 包括 如 下 内 

主题 资产 。 

org.Springframework.ui.context.ThemeSource 是 Spring 中 主题 资产 的 
接口 ，Spring 的 主题 需要 通过 ThemeSource 接 口 来 实现 存放 主题 信息 的 

org.Springframework.ui.context.support. ResourceBundleThemeSource 
是 ThemeSource 接 口 默认 实现 类 (也 就 是 通过 ResourceBundle 资 源 的 方 
式 定 义 主题 ) ， 在 Spring 中 的 配置 如 下 : 

<bean id="themeSource" 
class-"org.Springframework.ui.context.support. ResourceBundle 

ThemeSource"> 

<property name="basenamePrefix" value="com.test. "></property> 

</bean> 

默认 状态 下 是 在 类 路 径 根 目 录 下 查找 相应 的 资源 文件 ， 也 可 以 通 
过 basenamePrefix 来 制定 。 这 样 ，DispatcherServlet 就 会 在 com.test 包 下 
查找 资源 文件 。 

主题 解析 器 。 

ThemeSource 定义 了 一 些 主题 资源 ， 那 么 不 同 的 用 户 使 用 什么 主 
题 资 源 由 谁 定义 呢 ? org.Springframework.web.servlet.ThemeResolver 是 
主题 解析 器 的 接口 ， 主 题解 析 的 工作 便 是 由 它 的 子 类 来 完成 。 

对 于 主题 解析 器 的 子 类 主要 有 3 个 比较 常用 的 实现 。 以 主题 文件 
summer.properties 为 例 。 

n FixedThemeResolver 用 于 选择 一 个 固定 的 主题 。 

<bean id="themeResolver" 
class="org.Springframework.web.servlet.theme.FixedTheme Resolver"> 


<property name="defaultThemeName" value="summer"/> 


</bean> 

以 上 配置 的 作用 是 设置 主题 文件 为 summer.properties， 在 整个 项 目 
内 固定 不 变 。 

o CookieThemeResolver 用 于 实现 用 户 所 选 的 主题 ， 以 cookie 的 形 
式 存 放 在 客户 端的 机 器 上 ， 配 置 如 下 : 

<bean id="themeResolver" 
class="org.Springframework.web.servlet.theme.CookieThemeResolver"> 

<property name="defaultThemeName" value="summer"/> 

</bean> 

pSessionThemeResolver 用 于 主题 保存 在 用 户 的 HTTP Session. 

<bean id="themeResolver" 
class="org.Springframework.web.servlet.theme.SessionThemeResolver"> 


«property name="defaultThemeName" value="summer"/> 


</bean> 
以 上 配置 用 于 设置 主题 名 称 ， 并 且 将 该 名 称 保存 在 用 户 的 
HttpSession 中 。 


q AbstractThemeResolver 是 一 个 抽象 类 被 SessionThemeResolver 和 
FixedThemeResolver 继 承 ， 用 户 也 可 以 继承 它 来 自 定 义 主题 解析 器 。 

拦截 器 。 

如 果 需 要 根据 用 户 请 求 来 改变 主题 ， 那 么 Spring 提供 了 一 个 已 经 
实现 的 拦截 器 Theme ChangeInterceptor 拦 截 器 了 ， 配 置 如 下 : 

<bean id="themeChangelInterceptor" 
class="org.Springframework.web.servlet.theme. Theme 

ChangelInterceptor'"> 

<property name="paramName" value="themeName"></property> 


</bean> 


其 中 设置 用 户 请 求 参 数 名 为 themeName， 即 URL 为 ?themeName= 
具体 的 主题 名 称 。 此 外 ， 还 需要 在 handlerMapping 中 配置 拦截 器 。 当 
然 需 要 在 HandleMapping 中 添加 拦截 器 。 

<property name="interceptors"> 

<list> 
«ref local="themeChangelnterceptor" /> 
</list> 

</property> 

了 解 了 主题 文件 的 简单 使 用 方式 后 ， 再 来 查看 解析 器 的 初始 化 工 
作 ， 与 其 他 变量 的 初始 化 工作 相同 ， 主 题 文 件 解析 器 的 初始 化 工作 并 

没有 任何 特别 需要 说 明 的 地 方 。 

private void initThemeResolver(ApplicationContext context) 1 

try { 
this.themeResolver = 
context.getBean(THEME RESOLVER BEAN NAME, ThemeResolver. 
class); 
if (logger.isDebugEnabled()) 1 
logger.debug(" Using ThemeResolver [" + this.themeResolver 
+"); 


catch (NoSuchBeanDefinitionException ex) { 
// We need to use the default. 
this.themeResolver = getDefaultStrategy(context, 
ThemeResolver.class); 
if (logger.isDebugEnabled()) { 
logger.debug( 


"Unable to locate ThemeResolver with name " + THEME . 
RESOLVER BEAN NAME + "': using default [" + 


this.themeResolver + "]"); 


} 

(4) 初始 化 HandlerMappings。 

当 客 户 端 发 出 Request 时 DispatcherServlet 会 将 Request 提交 给 
HandlerMapping， 然 后 HanlerMapping 根据 Web Application Context 的 
配置 来 回 传 给 DispatcherServlet 相应 的 Controller。 

在 基于 SpringMVC 的 Web 应 用 程序 中 ， 我 们 可 以 为 
DispatcherServlet 提供 多 个 Handler Mapping 供 其 使 用 。 
DispatcherServlet 在 选用 HandlerMapping 的 过 程 中 ， 将 根据 我 们 所 指定 
的 一 系列 HandlerMapping 的 优先 级 进行 排序 ， 然 后 优先 使 用 优先 级 在 
前 的 HandlerMapping。 如 果 当 前 的 HandlerMapping 能 够 返回 可 用 的 
Handler，DispatcherServlet 则 使 用 当前 返回 的 Handler 进 行 Web 请 求 的 处 
理 ， 而 不 再 继续 询问 其 他 的 HandlerMapping。 否 则 ，DispatcherServlet 
将 继续 按照 各 个 HandlerMapping 的 优先 级 进行 询问 ， 直 到 获取 一 个 可 
用 的 Handler 为 止 。 初 始 化 配置 如 下 : 

private void initHandlerMappings(ApplicationContext context) 1 

this.handlerMappings - null; 

if (this.detectAllHandlerMappings) 1 
Map<String, HandlerMapping> matchingBeans = 
BeanFactoryUtils.beansOfTypeIncludingAncestors(context, 
HandlerMapping. class, true, false); 
if (ImatchingBeans.isEmpty()) 1 


this.handlerMappings = new ArrayList<HandlerMapping> 
(matchingBeans. 


values()); 
// We keep HandlerMappings in sorted order. 
OrderComparator.sort(this.handlerMappings); 


j 
else { 
try { 
HandlerMapping hm = 
context.getBean(HANDLER MAPPING BEAN NAME, 
HandlerMapping.class); 


this.handlerMappings = Collections.singletonList(hm); 
} 


catch (NoSuchBeanDefinitionException ex) { 


// Ignore, we'll add a default HandlerMapping later. 


} 


// Ensure we have at least one HandlerMapping, by registering 
// a default HandlerMapping if no other mappings are found. 
if (this.handlerMappings == null) { 


this.handlerMappings = getDefaultStrategies(context, 
HandlerMapping.class); 


if (logger.isDebugEnabled()) { 


logger.debug("No HandlerMappings found in servlet ' + 
getServletName() 


+ "' using default"); 


默认 情况 下 ，SpringMVC 将 加 载 当 前 系统 中 所 有 实现 了 
HandlerMapping 接 口 的 bean。 如 果 只 期 望 SpringMVC 加 载 指 定 的 
handlermapping 时 ， 可 以 修改 web.xml 中 的 DispatcherServlet 的 初始 参 
数 ， 将 detectAllHandlerMappings 的 值 设置 为 false: 

<init-param> 

<param-name>detectAllHandlerMappings</param-name> 
<param-value>false</param-value> 

</init-param> 

此 时 ， SpringMVC 将 查找 名 为 "handlerMapping” 的 bean ， 并 作 
为 当前 系统 中 唯一 的 handlermapping。 如果 没有 定义 handlerMapping 的 
话 ， 则 SpringMVC 将 按照 org.Springframework. 
web.servlet.DispatcherServlet 所 在 目录 下 的 
DispatcherServlet.properties 中 所 定义 的 
org.Springframework.web.servlet.HandlerMapping 的 内 容 来 加 载 默认 的 
handlerMapping 《用户 没有 自 定义 Strategies 的 情况 下 ) o 

(5) 初始 化 HandlerAdapters。 

从 名 字 也 能 联想 到 这 是 一 个 典型 的 适配器 模式 的 使 用 ， 在 计算 机 
编程 中 ， 适 配器 模式 将 一 个 类 的 接口 适 配 成 用 户 所 期 待 的 。 使 用 适 配 
器 ， 可 以 使 接口 不 兼容 而 无 法 在 一 起 工作 的 类 协同 工作 ， 做 法 是 将 类 
自己 的 接口 包 右 在 一 个 已 存在 的 类 中 。 那 么 在 处 理 handler 时 为 什么 会 
使 用 适配器 模式 呢 ? 回答 这 个 问题 我 们 首先 要 分 析 它 的 初始 化 逻辑 。 

private void initHandlerAdapters(ApplicationContext context) { 

this.handlerAdapters = null; 
if (this.detectAllHandlerAdapters) { 


// Find all HandlerAdapters in the ApplicationContext, including 
ancestor 


contexts. 
Map<String, HandlerAdapter> matchingBeans = 


BeanFactoryUtils.beansOfTypeIncludingAncestors(context, 
HandlerA dapter.class, true, false); 


if (!ImatchingBeans.isEmpty()) 1 


this.handlerAdapters = new ArrayList<HandlerAdapter> 
(matchingBeans. 


values()); 


// We keep HandlerAdapters in sorted order. 
OrderComparator.sort(this.handlerAdapters); 


j 
else { 
try { 
HandlerAdapter ha = 
context.getBean(HANDLER, ADAPTER, BEAN NAME, 
HandlerAdapter.class); 


this.handlerAdapters = Collections.singletonList(ha); 
} 


catch (NoSuchBeanDefinitionException ex) { 


// Ignore, we'll add a default HandlerAdapter later. 


} 


// Ensure we have at least some HandlerAdapters, by registering 


// default HandlerAdapters if no other adapters are found. 


if (this.handlerAdapters —- null) { 
this.handlerAdapters = getDefaultStrategies(context, 
HandlerAdapter.class); 
if (logger.isDebugEnabled()) { 
logger.debug("No HandlerAdapters found in servlet ™ + 
getServletName() 


+ "' using default"); 


} 
同样 在 初始 化 的 过 程 中 涉及 了 一 个 变量 detectAllHandlerAdapters， 
detectAllHandlerAdapters 作 用 和 detectAllHandlerMappings 类 似 ， 只 不 过 
作用 对 象 为 handlerAdapter。 亦 可 通过 如 下 配置 来 强制 系统 只 加 载 bean 
name/J“handlerAdapter”handlerAdaptero 
<init-param> 
<param-name>detectAllHandlerAdapters</param-name> 
<param-value>false</param-value> 
</init-param> 
如 果 无 法 找到 对 应 的 bean， 那 么 系统 会 尝试 加 载 默认 的 适配器 。 
protected <T> List<T> getDefaultStrategies(ApplicationContext 
context, Class<T> 
strategyInterface) { 
String key = strategyInterface.getName(); 
String value = defaultStrategies.getProperty(key); 
if (value != null) { 
String[] classNames = 


StringUtils.commaDelimitedListToStringArray(value); 


List<T> strategies = new ArrayList<T>(classNames.length); 
for (String className : classNames) { 

try { 

Class<?> clazz = ClassUtils.forName(className, 
DispatcherServlet. 

class.getClassLoader()); 
Object strategy = createDefaultStrategy(context, clazz); 
strategies.add((T) strategy); 

} 

catch (ClassNotFoundException ex) { 
throw new BeanlnitializationException( 
"Could not find DispatcherServlet's default strategy 
class [" + className + 
"] for interface [" + key + "]", ex); 

} 

catch (LinkageError err) { 
throw new BeanlnitializationException( 
"Error loading DispatcherServlet's default strategy 
class [" + className + 
"] for interface [" + key + "]: problem with 


class file or dependent class", err); 


return strategies; 
} 
else { 


return new LinkedList<T>(); 


} 
在 getDefaultStrategies RIANA, Spring 会 尝试 从 defaultStrategies 
中 加 载 对 应 的 HandlerAdapter 的 属性 ， 那 么 defaultStrategies 是 如 何 初 始 
化 的 呢 ? 
在 当前 类 DispatcherServlet 中 存在 这 样 一 段 初 始 化 代码 块 : 
static 1 
try { 
// DEFAULT STRATEGIES PATH - 
"DispatcherServlet.properties"; 
ClassPathResource resource = new 
ClassPathResource(DEFAULT STRATEGIES PATH, 
DispatcherServlet.class); 
defaultStrategies = 
PropertiesLoaderUtils.loadProperties(resource); 
} 
catch (IOException ex) { 
throw new IllegalStateException(" Could not load 'Dispatcher 
Servlet. 


properties": " + ex.getMessage()); 


j 

在 系统 加 载 的 时 候 ，defaultStrategies 根 据 当前 路 径 
DispatcherServlet.properties 来 初始 化 本 身 ， 查 看 
DispatcherServlet.properties 中 对 应 于 HandlerAdapter 的 属性 : 

org.Springframework.web.servlet.HandlerAdapter=org.Springframewo 


rk.web.servlet.mvc.Htt 


pRequestHandlerAdapter, \ 


org.Springframework.web.servlet.mvc.SimpleControllerHandlerAdapter,\ 


org.Springframework.web.servlet.mvc.annotation. AnnotationMethodHandl 
erAdapter 

由 此 得 知 ， 如 果 程 序 开发 人 员 没 有 在 配置 文件 中 定义 自己 的 适 配 
器 ， 那 么 Spring 会 默认 加 载 配 置 文件 中 的 3 个 适配器 。 

作为 总 控制 器 的 派 遗 器 servlet 通 过 处 理 器 映射 得 到 处 理 器 后 ， 会 
轮 询 处 理 器 适配器 模块 ， 查 找 能 够 处 理 当 前 HTTP 请 求 的 处 理 器 适配器 
的 实现 ， 处 理 器 适配器 模块 根据 处 理 器 映射 返回 的 处 理 器 类 型 ， 例 如 
简单 的 控制 器 类 型 、 注 解 控 制 器 类 型 或 者 远程 调用 处 理 器 类 型 ， 来 选 
择 某 一 个 适当 的 处 理 器 适配器 的 实现 ， 从 而 适 配 当 前 的 HTTP 请 求 。 

HTTP 请 求 处 理 器 适配器 (HttpRequestHandlerAdapter) o 

HTTP 请 求 处 理 器 适配器 仅 仪 支持 对 HTTP 请 求 处 理 器 的 适 配 。 它 
简单 地 将 HTTP 请 求 对 象 和 响应 对 象 传递 给 HTTP 请 求 处 理 器 的 实现 ， 
它 并 不 需要 返回 值 。 它 主要 应 用 在 基于 HITP 的 远程 调用 的 实现 上 。 

简单 控制 器 处 理 器 适配器 (SimpleControllerHandlerAdapter) 。 

这 个 实现 类 将 HTTP 请 求 适 配 到 一 个 控制 器 的 实现 进行 处 理 。 这 里 
控制 器 的 实现 是 一 个 简单 的 控制 器 接口 的 实现 。 简 单 控制 器 处 理 器 适 
配器 被 设计 成 一 个 框架 类 的 实现 ， 不 需要 被 改 瑟 ， 客 户 化 的 业务 逻辑 
通常 是 在 控制 器 接口 的 实现 类 中 实现 的 。 

注解 方法 处 理 器 适配器 (AnnotationMethodHandlerAdapter) 。 

这 个 类 的 实现 是 基于 注解 的 实现 ， 它 需要 结合 注解 方法 映射 和 注 
解 方 法 处 理 器 协同 工作 。 它 通过 解析 声明 在 注解 控制 器 的 请 求 映射 信 
息 来 解析 相应 的 处 理 器 方法 来 处 理 当 前 的 HTTP 请 求 。 在 处 理 的 过 程 
中 ， 它 通过 反射 来 发 现 探 测 处 理 器 方法 的 参数 ， 调 用 处 理 器 方法 ， 并 


且 映 射 返回 值 到 模型 和 控制 器 对 象 ， 最 后 返回 模型 和 控制 妖 对 象 给 作 
为 主 控制 器 的 派遣 器 Servlet。 

所 以 我 们 现在 基本 上 可 以 回答 之 前 的 问题 了 ，Spring 中 所 使 用 的 
Handler 并 没有 任何 特殊 的 联系 ， 但 是 为 了 统一 处 理 ，Spring 提 供 了 不 
同情 况 下 的 适配器 。 

(6) 初始 化 HandlerExceptionResolvers。 

基于 HandlerExceptionResolver 接 口 的 异常 处 理 ， 使 用 这 种 方式 只 
需要 实现 resolveException 方 法 ， 该 方法 返回 一 个 ModelAndView 对 象 ， 
在 方法 内 部 对 异常 的 类 型 进行 判断 ， 然 后 尝试 生成 对 应 的 
ModelAndView 对 象 ， 如 果 该 方法 返回 了 null, M Spring 会 继续 寻找 
其 他 的 实现 了 HandlerExceptionResolver 接 口 的 bean。 换 句 话说 ，Spring 
会 搜索 所 有 注册 在 其 环境 中 的 实现 了 HandlerExceptionResolver 接 口 的 
bean， 逐 个 执行 ， 直 到 返回 了 一 个 ModelAndView 对 象 。 

import javax.servlet.http.HttpServletRequest; 

import javax.servlet.http.HttpServletResponse; 

import org.apache.commons.logging.Log; 

import org.apache.commons.logging.LogFactory; 

import org.Springframework.stereotype.Component; 

import org.Springframework.web.servlet. HandlerExceptionResolver; 

import org.Springframework.web.servlet. ModelAndView; 

(Q Component 

public class ExceptionHandler implements HandlerExceptionResolver 

{ 

private static final Log logs = 
LogFactory.getLog(ExceptionHandler.class); 
@Override 


public ModelAndView resolveException(HttpServletRequest 
request, HttpServletResponse 
response, Object obj, 


Exception exception) 


request.setA ttribute(" exception", exception.toString()); 
request.setAttribute("exceptionStack", exception); 
logs.error(exception.toString(), exception); 


return new ModelAndView("error/exception"); 


j 
这 个 类 必须 声明 到 Spring 中 去 ， 让 Spring 管理 它 ， 在 Spring 的 配置 
文件 applicationContext.xml 中 增加 以 下 内 容 : 
<bean id="exceptionHandler" 
class="com.test.exception.MyExceptionHandler"/> 
初始 化 代码 如 下 : 
private void initHandlerExceptionResolvers(ApplicationContext 
context) 1 
this.handlerExceptionResolvers - null; 
if (this.detectAllHandlerExceptionResolvers) 1 
// Find all HandlerExceptionResolvers in the ApplicationContext, 
including 
ancestor contexts. 
Map<String, HandlerExceptionResolver> matchingBeans = 
BeanFactoryUtils 
.beansOfTypeIncludingAncestors(context, 


HandlerExceptionResolver. 


class, true, false); 
if (ImatchingBeans.isEmpty()) 1 
this.handlerExceptionResolvers = new ArrayList<Handler 
Exception 
Resolver>(matchingBeans.values()); 
// We keep HandlerExceptionResolvers in sorted order. 


OrderComparator.sort(this.handlerExceptionResolvers); 


} 
else { 
try { 
HandlerExceptionResolver her = 


context.getBean(HANDLER, EXCEPTION RESOLVER, BEAN NAME, 
HandlerExceptionResolver.class); 
this.handlerExceptionResolvers = 
Collections.singletonList(her); 
j 
catch (NoSuchBeanDefinitionException ex) 1 


// Ignore, no HandlerExceptionResolver is fine too. 


} 

// Ensure we have at least some HandlerExceptionResolvers, by 
registering 

// default HandlerExceptionResolvers if no other resolvers are 
found. 


if (this.handlerExceptionResolvers == null) { 


this.handlerExceptionResolvers = getDefaultStrategies(context, 
Handler 
ExceptionResolver.class); 
if (logger.isDebugEnabled()) { 
logger.debug("No HandlerExceptionResolvers found in servlet 
HE 


getServletName() + ": using default"); 


} 
(7) 初始 化 RequestToViewNameTranslatoro 

当 Controller 处 理 器 方法 没有 返回 一 个 View 对 象 或 逻辑 视图 名 称 ， 
并 且 在 该 方法 中 没有 直接 往 response 的 输出 流 里 面 写 数据 的 时 候 ， 
Spring 就 会 采用 约定 好 的 方式 提供 一 个 逻辑 视图 名 称 。 这 个 逻辑 视图 
名 称 是 通过 Spring 定义 的 
org.Springframework.web.servlet.RequestTo View NameTranslator 接 口 的 
getViewName 方 法 来 实现 的 ， 我 们 可 以 实现 自己 的 Request 
ToViewName Translator 接 口 来 约定 好 没有 返回 视图 名 称 的 时 候 如 何 确 
定 视图 名 称 。Spring 已 经 给 我 们 提供 了 一 个 它 自己 的 实现 ， 那 就 是 
org.Springframework.web.servlet.view.DefaultRequest 
ToViewName&nbsp;Translatoro 

在 介绍 DefaultRequestToViewNameTranslator 是 如 何 约定 视图 名 称 
之 前 ， 先 来 看 一 下 它 支 持 用 户 定义 的 属性 。 

prefix: 前 缀 ， 表 示 约 定好 的 视图 名 称 需 要 加 上 的 前 缀 ， 默 认 是 空 
Fo 

suffix: 后 缀 ， 表 示 约 定好 的 视图 名 称 需 要 加 上 的 后 缀 ， 默 认 是 空 
FRo 


separator: 分 隔行 ， 默 认 是 科 杠 “/”。 

stripLeadingSlash: 如 果 首 字符 是 分 隔 符 ， 是 否 要 去 除 ， 默 认 是 
trueo 

stripIrailingSlash: 如 果 最 后 一 个 字符 是 分 隔 符 ， 是 否 要 去 除 ， 默 
认 是 true。 

stripExtension: 如 果 请 求 路 径 包 含 扩 展 名 是 否 要 去 除 ， 默 认 是 
trueo 

urlDecode: 是 否 需要 对 URL 解码 ， 默 认 是 true. CARA 
request 指定 的 编码 或 者 [SO-8859-1 编 码 对 URL 进 行 解码 。 

当 我 们 没有 在 SpringMVC 的 配置 文件 中 手动 的 定义 一 个 名 为 
viewNameTranlator 的 Bean 的 时 候 ，Spring 就 会 为 我 们 提供 一 个 默认 的 
viewNameTranslator， 即 DefaultRequest ToViewName Translator. 

接 下 来 看 一 下 ， 当 Controller 处 理 器 方法 没有 返回 逻辑 视图 名 称 
时 ，DefaultRequestToView NameTranslator 是 如 何 约定 视图 名 称 的 。 
DefaultRequestToViewNameTranslator 会 获取 到 请 求 的 URI， 然 后 根据 
提供 的 属性 做 一 些 改 造 ， 把 改造 之 后 的 结果 作为 视图 名 称 返回 。 这 里 
以 请 求 路 径 http://localhost/app/test/index.html 为 例 ， 来 说 明 一 下 
DefaultRequestToViewNameTranslator 是 如 何 工 作 的 。 该 请 求 路 径 对 应 
的 请 求 URI 为 /test/index.html， 我 们 来 看 以 下 几 种 情况 ， 它 分 别 对 应 的 
逻辑 视图 名 称 是 什么 。 

prefix 和 suffix 如 果 都 存在 ， 其 他 为 默认 值 ， 那 么 对 应 返回 的 逻辑 
视图 名 称 应 该 是 prefixtest/indexsuffix。 

stripLeadingSlash 和 stripExtension 都 为 false， 其 他 默认 ， 这 时 候 对 
应 的 逻辑 视图 名 称 是 /product/index.html。 

都 采用 默认 配置 时 ， 返 回 的 逻辑 视图 名 称 应 该 是 product/indexo 

如 果 人 逻辑 视图 名 称 跟 请 求 路 径 相同 或 者 相关 关系 都 是 一 样 的 ， 那 
么 我 们 就 可 以 采用 Spring 为 我 们 事先 约定 好 的 逻辑 视图 名 称 返 回 ， 这 


可 以 大 大 简化 我 们 的 开发 工作 ， 而 以 上 功能 实现 的 关键 属 性 
viewNameTranslator， 则 是 在 initRequestToViewNameTranslator 中 完 
成 。 
private void initRequestIoViewNameTIranslator(ApplicationContext 
context) 1 
try { 
this. viewNameTranslator = 


context.getBean(REQUEST TO VIEW NAME TRANSLATOR BEAN _ 
NAME, 
RequestToViewNameTranslator.class); 
if (logger.isDebugEnabled()) { 
logger.debug(" Using RequestToViewNameTranslator [" + 
this. viewName 


Translator + "]"); 


} 
catch (NoSuchBeanDefinitionException ex) { 
// We need to use the default. 
this. viewNameTranslator = getDefaultStrategy(context, 
RequestTo ViewName 
Translator.class); 
if (logger.isDebugEnabled()) { 
logger.debug( Unable to locate 


RequestToViewNameTranslator with name " + 


REQUEST TO VIEW NAME TRANSLATOR BEAN NAME +": 


Using default 
[" + this. viewNameTranslator + 


T 


} 

(8) 初始 化 ViewResolvers。 

在 SpringMVC 中 ， 当 Controller 将 请 求 处 理 结果 放 入 到 
ModelAndView 中 以 后 ， DispatcherServlet 会 根据 ModelAndView 选 择 
合适 的 视图 进行 渲染。 那么 在 SpringMVC 中 是 如 何 选择 合适 的 View 
WE? View 对 象 是 是 如 何 创建 的 呢 ? 答案 就 在 ViewResolver 中 。 
ViewResolver 接 口 定 义 了 resolverViewName 方 法 ， 根 据 viewName 创 建 
合适 类 型 的 View 实 现 。 

那么 如 何 配置 ViewResolver 呢 ? 在 Spring 中 ，ViewResolver 作 为 
Spring Bean 存 在 ， 可 以 在 Spring 配置 文件 中 进行 配置 ， 例 如 下 面 的 代 
码 ， 配 置 了 JSP 相 天 的 viewResolver。 

<bean 
class-"org.Springframework.web.servlet.view.InternalResourceViewResolv 
er"> 

«property name-"prefix" value="/WEB-INF/views/"/> 
«property name="suffix" value=".jsp"/> 

</bean> 

viewResolvers 属 性 的 初始 化 工作 在 initViewResolvers 中 完成 。 

private void initViewResolvers(ApplicationContext context) 1 

this.viewResolvers - null; 
if (this.detectAll ViewResolvers) 1 


// Find all ViewResolvers in the ApplicationContext, including 
ancestor 
contexts. 
Map<String, ViewResolver> matchingBeans = 
BeanFactory Utils.beansOfTypeIncludingAncestors(context, 
ViewResolver.class, true, false); 
if (ImatchingBeans.isEmpty()) { 
this.viewResolvers = new ArrayList<ViewResolver> 
(matchingBeans. 
values()); 
// We keep ViewResolvers in sorted order. 


OrderComparator.sort(this.viewResolvers); 


j 
else { 
try { 
ViewResolver vr = 
context.getBean( VIEW RESOLVER, BEAN NAME, ViewResolver. 
class); 
this.viewResolvers = Collections.singletonList(vr); 
j 
catch (NoSuchBeanDefinitionException ex) 1 


// Ignore, we'll add a default ViewResolver later. 


} 
// Ensure we have at least one ViewResolver, by registering 


// a default ViewResolver if no other resolvers are found. 


if (this.viewResolvers == null) { 
this.viewResolvers = getDefaultStrategies(context, 
ViewResolver.class); 
if (logger.isDebugEnabled()) { 
logger.debug("No ViewResolvers found in servlet "+ 
getServletName() 


+ "' using default"); 


j 
(9) 初始 化 FlashMapManager。 
SpringMVC Flash attributes 提 供 了 一 个 请 求 存 储 属性 ， 可 供 其 他 请 
求 使 用 。 在 使 用 重 定 向 时 候 非常 必要 ， 例 如 PosVRedirectGet 模 式 。 
Flash attributes 在 重 定向 之 前 暂 存 (就 像 存 在 session 中 ) 以 便 重 定向 之 
后 还 能 使 用 ， 并 立即 删除 。 
SpringMVC 有 两 个 主要 的 抽象 来 支持 flash attributes。FlashMap 用 
于 保持 flash attributes, [ff] FlashMapManager 用 于 存储 、 检 索 、 管 理 
FlashMap 实 例 。 
flash attribute 支 持 默 认 开 启 ("on") 并 不 需要 显 式 启用 ， 它 永远 不 
会 导致 HTTP Session 的 创建 。 这 两 个 FlashMap 实 例 都 可 以 通过 静态 方 
法 RequestContextUtils 从 Spring MVC 的 任何 位 置 访问 。 
flashMapManager 的 初始 化 在 initFlashMapManager 中 完成 。 
private void initFlashMapManager(ApplicationContext context) 1 
try { 
this.flashMapManager = 
context.getBean(FLASH MAP MANAGER BEAN NAME, 
FlashMapManager.class); 


if (logger.isDebugEnabled()) { 
logger.debug(" Using FlashMapManager [" + 
this.flashMapManager + "]"); 
} 
} 
catch (NoSuchBeanDefinitionException ex) { 
// We need to use the default. 
this.flashMapManager = getDefaultStrategy(context, 
FlashMapManager. 
class); 
if (logger.isDebugEnabled()) { 
logger.debug(" Unable to locate FlashMapManager with name 
iu 
FLASH. MAP MANAGER BEAN NAME + "': using 
default [" + 
this.flashMapManager + "]"); 


} 
11.4 Dispatcherservlet 的 逻辑 处 理 


根据 之 前 的 示例 ， 我 们 知道 在 HttpServlet 类 中 分 别提 供 了 相应 的 
服务 方法 ， 它 们 是 doDelete()、doGet()、doOptions()、doPost()、 
doPut() 和 doTrace()， 它 会 根据 请 求 的 不 同形 式 将 程序 引导 至 对 应 的 也 
数 进 行 处 理 。 这 几 个 痕 数 中 最 常用 的 遂 数 无 非 就 是 doGet() 和 doPost()， 
那么 我 们 就 直接 查看 DispatcherServlet 中 对 于 这 两 个 函数 的 逻辑 实现 。 


@Override 
protected final void doGet(HttpServletRequest request, 
HttpServletResponse response) 
throws ServletException, IOException { 
processRequest(request, response); 
} 
@Override 
protected final void doPost(HttpServletRequest request, 
HttpServletResponse response) 
throws ServletException, IOException { 
processRequest(request, response); 
} 
对 于 不 同 的 方法 ，Spring 并 没有 做 特殊 处 理 ， 而 是 统一 将 程序 再 
一 次 地 引导 至 process Request(request, response) 中 。 
protected final void processRequest(HttpServletRequest request, 
HttpServletResponse 
response) 
throws ServletException, IOException 1 
/记录 当前 时 间 ， 用 于 计算 web 请 求 的 处 理 时 间 
long startTime = System.currentTimeMillis(); 
Throwable failureCause - null; 
// Expose current LocaleResolver and request as LocaleContext. 
LocaleContext previousLocaleContext = 


LocaleContextHolder.getLocaleContext(); 


LocaleContextHolder.setLocaleContext(buildLocaleContext(request), 


this.threadContextInheritable); 


// Expose current RequestAttributes to current thread. 
RequestAttributes previousRequestAttributes = 
RequestContextHolder. GetRequest 
Attributes(); 
ServletRequestAttributes requestAttributes = null; 
if (previousRequestAttributes == null || previousRequestA ttributes. 
getClass(). 
equals(ServletRequestAttributes.class)) 1 
requestAttributes = new ServletRequestAttributes(request); 
RequestContextHolder.setRequestAttributes(requestA ttributes, 
this.threadContextInheritable); 
j 
if (logger.isTraceEnabled()) 1 
logger.trace("Bound request context to thread: " + request); 
j 
try { 
doService(request, response); 
j 
catch (ServletException ex) 1 
failureCause = ex; 
throw ex; 
j 
catch (IOException ex) 1 
failureCause = ex; 
throw ex; 
j 
catch (Throwable ex) 1 


failureCause = ex; 
throw new NestedServletException("Request processing failed", 
ex); 
j 
finally { 


// Clear request attributes and reset thread-bound context. 


LocaleContextHolder.setLocaleContext(previousLocaleContext,this.thread 
Context 

Inheritable); 

if (requestAttributes != null) { 


RequestContextHolder.setRequestAttributes(previousRequestAttributes, 
this.threadContextInheritable); 
requestAttributes.requestCompleted(); 

} 
if (logger.isTraceEnabled()) { 
logger.trace("Cleared thread-bound request context: " + 
request); 
j 
if (logger.isDebugEnabled()) 1 
if (failureCause !- null) 1 
this.logger.debug(" Could not complete request", 
failureCause); 
j 
else { 


this.logger.debug(" Successfully completed request"); 


j 

if (this.publishEvents) ( 
// Whether or not we succeeded, publish an event. 
long processingTime = System.currentTimeMillis() - 

startTime; 

this.webApplicationContext.publishEvent( 
new ServletRequestHandledEvent(this, 
request.getRequestURI(), request.getRemoteA ddr(), 
request.getMethod(), 
getServletConfig().getServletName(), 
WebUtils.getSessionId(request), 
getUsernameForRequest(request), 


processingTime, failureCause)); 


} 
函数 中 已 经 开始 了 对 请 求 的 处 理 ， 虽 然 把 细节 转移 到 了 doService 
函数 中 实现 ， 但 是 我 们 不 难看 出 处 理 请 求 前 后 所 做 的 准备 与 处 理工 
作 。 
(1) 为 了 保证 当前 线程 的 LocaleContext 以 及 RequestAttributes 可 
以 在 当前 请 求 后 还 能 恢复 ， 提 取 当 前 线程 的 两 个 属性 。 
(2) 根据 当前 request 创 建 对 应 的 LocaleContext 和 
RequestAttributes， 并 绑 定 到 当前 线程 。 
(3) 委托 给 doService 方 法 进一步 处 理 。 
(4) 请 求 处 理 结束 后 恢复 线程 到 原始 状态 。 
(5) 请 求 处 理 结束 后 无 论 成 功 与 否 发 布 事件 通知 。 


继续 查看 doService 方 法 。 
protected void doService(HttpServletRequest request, 
HttpServletResponse response) throws 
Exception 1 
if (logger.isDebugEnabled()) 1 
String requestUri = urlPathHelper.getRequestUri(request); 
logger.debug(" DispatcherServlet with name ™ + 
getServletName() + ” 
processing " + request.getMethod() + 
" request for [" + requestUri + "]"); 
} 
// Keep a snapshot of the request attributes in case of an include, 
// to be able to restore the original attributes after the include. 
Map<String, Object> attributesSnapshot = null; 
if (WebUtils.isIncludeRequest(request)) { 
logger.debug(" Taking snapshot of request attributes before 
include"); 
attributesSnapshot = new HashMap<String, Object>(); 
Enumeration<?> attrNames = request.getAttributeNames(); 
while (attrNames.hasMoreElements()) { 
String attrName = (String) attrNames.nextElement(); 


if (this.cleanupAfterInclude || attrName.startsWith 
("org.Springframework. 


web.servlet")) { 


attributesSnapshot.put(attrName, request.getAttribute 
(attrName)); 


} 


} 


// Make framework objects available to handlers and view objects. 


request.setAttribute(WEB APPLICATION CONTEXT ATTRIBUTE, 
getWebApplicationContext()); 

request.setAttribute(LOCALE RESOLVER, ATTRIBUTE, 
this.localeResolver); 

request.setAttribute(THEME RESOLVER, ATTRIBUTE, 
this.themeResolver); 

request.setAttribute(THEME SOURCE ATTRIBUTE, 
getThemeSource()); 

FlashMap inputFlashMap = 
this.flashMapManager.retrieveAndUpdate(request, 

response); 

if (inputFlashMap != null) { 

request.setAttribute(INPUT_FLASH_MAP_ATTRIBUTE, 
Collections.unmodifiableMap 
(inputFlashMap)); 

} 

request.setAttribute(OUTPUT FLASH MAP ATTRIBUTE, new 
FlashMap()); 

request.setAttribute(FLASH_ MAP MANAGER ATTRIBUTE, 
this.flashMapManager); 

try { 


doDispatch(request, response); 


finally { 
// Restore the original attribute snapshot, in case of an include. 
if (attributesSnapshot != null) { 


restoreAttributesA fterInclude(request, attributesSnapshot); 


j 
我 们 猜想 对 请 求 处 理 至 少 应 该 包括 一 些 诸如 寻找 Handler 并 页 面 跳 
转 之 类 的 逻辑 处 理 ， 但 是 ， 在 doService 中 我 们 并 没有 看 到 想 看 到 的 逻 
辑 ， 相 反 却 同样 是 一 些 准备 工作 ， 但 是 这 些 准 备 工作 却 是 必 不 可 少 
的 。Spring 将 已 经 初始 化 的 功能 辅助 工具 变量 ， 比 如 localeResolver、 
themeResolver 等 设置 在 request 属 性 中 ， 而 这 些 属性 会 在 接 下 来 的 处 理 
中 派 上 用 场 。 
经 过 层 层 的 准备 工作 ， 终 于 在 doDispatch 凶 | 数 中 看 到 了 完整 的 请 
求 处 理 过 程 。 
protected void doDispatch(HttpServletRequest request, 
HttpServletResponse response) 
throws Exception 1 
HttpServletRequest processedRequest = request; 
HandlerExecutionChain mappedHandler = null; 
int interceptorIndex = -1; 
try { 
ModelAndView mv; 
boolean errorView - false; 
try { 
/如 果 是 MultipartContent 类 型 的 request 则 转换 request 为 
MultipartHttpServletRequest 类 型 的 


request 
processedRequest = checkMultipart(request); 
/根据 request 信 息 寻 找 对 应 的 Handler 
mappedHandler = getHandler(processedRequest, false); 
if (mappedHandler == null || mappedHandler.getHandler() == 
null) { 
/如 果 没 有 找到 对 应 的 handler 则 通过 response 反 馈 错 误 信 息 


noHandlerFound(processedRequest, response); 


return; 
} 
/根据 当前 的 handler 寻 找 对 应 的 HandlerAdapter 
HandlerAdapter ha = 


getHandlerAdapter(mappedHandler.getHandler()); 
/如 果 当 前 handler 支 持 last-modified 头 处 理 
String method = request.getMethod(); 
boolean isGet = "GET".equals(method); 
if (isGet || ' HEAD".equals(method)) { 
long lastModified = ha.getLastModified(request, 
mappedHandler. 
getHandler()); 
if (logger.isDebugEnabled()) 1 
String requestUri = urlPathHelper.getRequestUri(request); 
logger.debug(" Last-Modified value for [" + requestUri + "] 
is: 
"+ lastModified); 


if (new ServletWebRequest(request, 
response).checkNotModified 
(lastModified) && isGet) { 


return; 


/拦截 器 的 preHandler 方 法 的 调用 
HandlerInterceptor[] interceptors = 
mappedHandler. getInterceptors(); 
if (interceptors != null) { 
for (int i = 0; i < interceptors.length; i++) { 
HandlerInterceptor interceptor = interceptors][i |; 
if (!interceptor.preHandle(processedRequest, response, 
mappedHandler.getHandler())) { 
triggerA fterCompletion(mappedHandler, 


interceptorIndex, 
processedRequest, response, null); 
return; 
} 
interceptorIndex = i; 
} 
} 


/真正 的 激活 handler 并 返回 视图 
mv = ha.handle(processedRequest, response, 
mappedHandler.getHandler()); 
IRL s EE IZ FE TS SANTI RI US REA 
if (mv != null && !mv.hasView()) { 


mv.setViewName(getDefaultViewName(request)); 
j 
/应 用 所 有 拦截 器 的 postHandle 方 法 
if (interceptors != null) { 
for (int i = interceptors.length - 1; i >= 0; i--) { 
HandlerInterceptor interceptor = interceptors][i |; 
interceptor.postHandle(processedRequest, response, 
mappedHandler. 
getHandler(), mv); 
} 


} 
catch (ModelAndViewDefiningException ex) { 
logger.debug("ModelAndViewDefiningException 
encountered", ex); 
mv = ex.getModelAndView(); 
} 
catch (Exception ex) { 
Object handler = (mappedHandler != null ? 
mappedHandler.getHandler() : null); 
mv =processHandlerException(processedRequest, response, 
handler, ex); 
errorView = (mv != null); 
} 
// Did the handler return a view to render? 
/如 果 在 Handler 实 例 的 处 理 中 返回 了 view， 那 么 需要 做 页 面 
的 处 理 


if (mv != null && !mv.wasCleared()) 1 
/处 理 页 面 跳 转 
render(mv, processedRequest, response); 
if (errorView) 1 


WebUtils.clearErrorRequestAttributes(request); 


} 
else { 
if (logger.isDebugEnabled()) { 
logger.debug("Null ModelAndView returned to 
DispatcherServlet 
with name "' + getServletName() + 


": assuming HandlerAdapter completed request handling"); 


j 
/完成 处 理 激 活 触发 器 
triggerAfterCompletion(mappedHandler, interceptorIndex, 
processedRequest, 
response, null); 
j 
catch (Exception ex) 1 
// Trigger after-completion for thrown exception. 
triggerAfterCompletion(mappedHandler, interceptorIndex, 
processedRequest, 
response, ex); 


throw ex; 


catch (Error err) 1 
ServletException ex = new NestedServletException(" Handler 
processing 
failed", err); 
// Trigger after-completion for thrown exception. 
triggerAfterCompletion(mappedHandler, interceptorIndex, 
processedRequest, 
response, ex); 
throw ex; 
l 
finally { 
// Clean up any resources used by a multipart request. 
if (processedRequest != request) { 


cleanupMultipart(processedRequest); 


} 

doDispatch EEX REM f. Spring 请 求 处 理 所 涉 及 的 主要 人 逻辑， 而 
我 们 之 前 设置 在 request 中 的 各 种 辅助 属性 也 都 有 被 派 上 了 用 场 。 下 面 
回顾 一 下 逻辑 处 理 的 全 过 程 。 


11.4.1 MultipartContent 类 型 的 request 处 理 


对 于 请 求 的 处 理 ，Spring 首 先 考 虑 的 是 对 于 Multipart 的 处 理 ， 如 果 
是 MultipartContent 类 型 的 request， 则 转换 request 为 
MultipartHttpServletRequest 类 型 的 request。 

protected HttpServletRequest checkMultipart(HttpServletRequest 


request) throws 


MultipartException { 
if (this.multipartResolver != null && 
this.multipartResolver.isMultipart(request)) 1 
if (request instanceof MultipartHttpServletRequest) 1 
logger.debug(" Request is already a 
MultipartHttpServletRequest - if not 
in a forward, " + 
"this typically results from an additional MultipartFilter in 
web.xml"); 
j 
else { 


return this.multipartResolver.resolveMultipart(request); 


} 


// Tf not returned before: return original request. 


return request; 


j 
11.4.2 根据 request 信 息 寻 找 对 应 的 Handler 


在 Spring 中 最 简单 的 映射 处 理 器 配置 如 下 : 
<bean id-"simpleUrlMapping" 


class-"org.Springframework.web.servlet.handler.SimpleUrlHandlerMappin 
g 
<property name="mappings"> 
<props> 


<prop key="/userlist.htm">userController</prop> 


</props> 
</property> 
</bean> 
在 Spring 加 载 的 过 程 中 ，Spring 会 将 类 型 为 
SimpleUrlHandlerMapping 的 实例 加 载 到 this.handlerMappings 中 ， 按 照 
常理 推断 ， 根 据 request 提 取 对 应 的 Handler， 无 非 就 是 提取 当前 实例 中 
的 userController， 但 是 userController 为 继承 目 AbstractController 类 型 实 
例 ， 与 Handler ExecutionChain 并 无 任何 关联 ， 那 么 这 一 步 是 如 何 封装 
的 呢 ? 
protected HandlerExecutionChain getHandler(HttpServletRequest 
request, boolean cache) 
throws Exception 1 
return getHandler(request); 
} 
protected HandlerExecutionChain getHandler(HttpServletRequest 
request) throws Exception 1 
for (HandlerMapping hm : this.handlerMappings) 1 
if (logger.isTraceEnabled()) { 
logger.trace( 
"Testing handler map [" + hm + "| in DispatcherServlet with 
name "' + getServletName() + ""); 
j 
HandlerExecutionChain handler = hm.getHandler(request); 
if (handler != null) { 


return handler; 


return null; 

} 

在 之 前 的 内 容 我 们 提 过 ， 在 系统 启动 时 Spring 会 将 所 有 的 映射 类 
型 的 bean 注册 到 this.handlerMappings 变量 中 ， 所 以 此 函数 的 目的 就 是 
遍历 所 有 的 HandlerMapping， 并 调用 其 getHandler 方 法 进行 封装 处 理 。 
以 SimpleUrlHandlerMapping 为 例 查 看 其 getHandler 方 法 如 下 : 

public final HandlerExecutionChain getHandler(HttpServletRequest 
request) throws 

Exception { 

/根据 request 获 取 对 应 的 handler 

Object handler = getHandlerInternal(request); 

if (handler == null) { 
/如 果 没 有 对 应 request 的 handler 则 使 用 默认 的 handler 
handler = getDefaultHandler(); 

j 

/如 果 也 没有 提供 默认 的 handler 则 无 法 继续 处 理 返 回 null 

if (handler == null) { 
return null; 
i 
// Bean name or resolved handler? 
if (handler instanceof String) { 
String handlerName = (String) handler; 
handler = getApplicationContext().getBean(handlerName); 
j 


return getHandlerExecutionChain(handler, request); 


孙 数 中 首先 会 使 用 getHandlerInternal 方法 根据 request 信息 获取 对 
应 的 Handler， 如 果 以 SimpleUrlHandlerMapping 为 例 分 析 ， 那 么 我 们 推 
断 此 步骤 提供 的 功能 很 可 能 就 是 根据 URL 找 到 匹配 的 Controller 并 返 
回 ， 当 然 如 果 没 有 找到 对 应 的 Controller 处 理 器 那么 程序 会 尝试 去 查找 
配置 中 的 默认 处 理 器 ， 当 然 ， 当 查找 的 controller 为 String 类 型 时 ， 那 就 
意味 着 返回 的 是 配置 的 bean 名 称 ， 需 要 根据 bean 名 称 查找 对 应 的 
bean， 最 后 ， 还 要 通过 getHandlerExecutionChain 方 法 对 返回 的 Handler 
进行 封装 ， 以 保证 满足 返回 类 型 的 匹配 。 下 面 详 细 分 析 这 个 过 程 。 

1. 根据 request 查 找 对 应 的 Handler 

首先 从 根据 request 查 找 对 应 的 Handler 开 始 分 析 。 

protected Object getHandlerInternal(HttpServletRequest request) 
throws Exception 1 

/截取 用 于 匹配 的 有 效 路 径 
String lookupPath = 
getUrlPathHelper().getLookupPathForRequest(request); 
/根据 路 径 寻 找 Handler 
Object handler = lookupHandler(lookupPath, request); 
if (handler == null) { 
Object rawHandler = null; 
if ("/".equals(lookupPath)) 1 
/如 果 请 求 的 路 径 仅 仅 是 >”， 那 么 使 用 RootHandler 进 行 
处 理 
rawHandler = getRootHandler(); 
} 
if (rawHandler == null) { 
// 无 法 找到 handler 则 使 用 默认 handler 
rawHandler = getDefaultHandler(); 


j 
if (rawHandler != null) { 
/根据 beanName 获 取 对 应 的 bean 
if (rawHandler instanceof String) 1 
String handlerName = (String) rawHandler; 
rawHandler = 
getApplicationContext().getBean(handlerName); 
j 
/模版 方法 
validateHandler(rawHandler, request); 
handler = buildPathExposingHandler(rawHandler, 
lookupPath, lookupPath, null); 
j 
j 
if (handler != null && logger.isDebugEnabled()) 1 
logger.debug(" Mapping [" + lookupPath + "] to " + handler); 
j 
else if (handler == null && logger.isTraceEnabled()) 1 
logger.trace("No handler mapping found for [" + lookupPath + 


return handler; 
l 
protected Object lookupHandler(String urlPath, HttpServletRequest 
request) throws Exception { 
/直接 匹配 情况 的 处 理 
Object handler = this.handlerMap.get(urlPath); 


if (handler != null) { 
// Bean name 
if (handler instanceof String) { 
String handlerName = (String) handler; 
handler = getApplicationContext().getBean(handlerName); 
} 
validateHandler(handler, request); 
return buildPathExposingHandler(handler, urlPath, urlPath, 
null); 
} 
// 通配符 匹配 的 处 理 
List<String> matchingPatterns = new ArrayList<String>(); 
for (String registeredPattern : this.handlerMap.keySet()) 1 
if (getPathMatcher().match(registeredPattern, urlPath)) 1 


matchingPatterns.add(registeredPattern); 


j 
String bestPatternMatch - null; 
Comparator<String> patternComparator = 
getPathMatcher().getPatternComparator(urlPath); 
if (!ImatchingPatterns.isEmpty()) 1 
Collections.sort(matchingPatterns, patternComparator); 
if (logger.isDebugEnabled()) { 
logger.debug(" Matching patterns for request [" + urlPath + 
"] are" + 


matchingPatterns); 


bestPatternMatch = matchingPatterns.get(0); 
j 
if (bestPatternMatch != null) { 
handler = this.handlerMap.get(bestPattern Match); 
// Bean name or resolved handler? 
if (handler instanceof String) { 
String handlerName = (String) handler; 
handler = getApplicationContext().getBean(handlerName); 
j 
validateHandler(handler, request); 
String pathWithinMapping = 
getPathMatcher().extractPathWithinPattern 
(bestPatternMatch, urlPath); 
// There might be multiple 'best patterns', let's make sure we 
have the correct 
URI template variables 
// for all of them 
Map<String, String> uriTemplateVariables = new 
LinkedHashMap<String, 
String>(); 
for (String matchingPattern : matchingPatterns) { 
if (patternComparator.compare(bestPatternMatch, 
matchingPattern) == 0) { 
uriTemplate Variables 
.putAll(getPathMatcher().extractUriTemplate Variables 
(matchingPattern, urlPath)); 


j 
if (logger.isDebugEnabled()) { 
logger.debug("URI Template variables for request [" + urlPath 
+"] are 
" + uriTemplate Variables); 
} 
returnbuildPathExposingHandler(handler, bestPatternMatch, 
pathWithinMapping, 
uriTemplate Variables); 
} 
// No handler found... 
return null; 
j 
根据 URL 获 取 对 应 Handler 的 匹配 规则 代码 实现 起 来 虽然 很 长 ， 但 
是 并 不 难 理解 ， 考 虑 了 直接 匹配 与 通配符 两 种 情况 。 其 中 要 提 及 的 是 
buildPathExposingHandler 函 数 ， 它 将 Handler 封 装 成 了 
HandlerExecutionChain 类 型 。 
protected Object buildPathExposingHandler(Object rawHandler, 
String bestMatchingPattern, 
String pathWithinMapping, Map<String, String> 
uri TemplateVariables) { 
HandlerExecutionChain chain = new 
HandlerExecutionChain(rawHandler); 
chain.addInterceptor(new 
PathExposingHandlerInterceptor(bestMatchingPattern, 
pathWithinMapping)); 
if (!CollectionUtils.isEmpty(uriTemplateVariables)) { 


chain.addInterceptor(new 
UriTemplateVariablesHandlerInterceptor (uri 
Template Variables)); 
j 


return chain; 


) 
在 函数 中 我 们 看 到 了 通过 将 Handler 以 参数 形式 传 入 ， 并 构建 


HandlerExecutionChain 类 型 实例 ， 加 入 了 两 个 拦截 器 。 此 时 我 们 似乎 
已 经 了 解 了 Spring 这 样 大 番 周 折 的 目的 。 链 处 理 机 制 ， 是 Spring 中 非常 
常用 的 处 理 方式 ， 是 AOP 中 的 重要 组 成 部 分 ， 可 以 方便 地 对 目标 对 象 
进行 扩展 及 拦截 ， 这 是 非常 优秀 的 设计 。 

2. 加 入 拦截 器 到 执行 链 

getHandlerExecutionChain 孙 数 最 主要 的 目的 是 将 配置 中 的 对 应 拦 
截 器 加 入 到 执行 链 中 ， 以 保证 这 些 拦 截 器 可 以 有 效 地 作用 于 目标 对 
象 。 


protected HandlerExecutionChain getHandlerExecutionChain(Object 


handler, HttpServletRequest 
request) 1 

HandlerExecutionChain chain = 

(handler instanceof HandlerExecutionChain) ? 

(HandlerExecutionChain) handler : new 
HandlerExecutionChain(handler); 

chain.addInterceptors(getA daptedInterceptors()); 

String lookupPath = 
urlPathHelper.getLookupPathForRequest(request); 

for (MappedInterceptor mappedInterceptor : mappedInterceptors) 1 

if (mappedInterceptor.matches(lookupPath, pathMatcher)) 1 


chain.addInterceptor(mappedInterceptor.getInterceptor()); 


} 


return chain; 


} 
11.4.3 没 找到 对 应 的 Handler 


每 个 请 求 都 应 该 对 应 着 一 Handler， 因 为 每 个 请 求 都 会 在 后 台 有 相 
应 的 逻辑 对 应 ， 而 逻辑 的 实现 就 是 在 Handler 中 ， 所 以 一 旦 遇 到 没有 找 
青 况 (正常 情况 下 如 果 没 有 URL 匹配 的 Handler， 开 发 人 员 
可 以 设置 默认 的 Handler 来 处 理 请 求 ， = 日 是 如 果 默 认 请 求 也 未 设置 融会 
出 现 Handler 为 空 的 情况 ) ， 就 只 能 通过 response 向 用 户 返回 错误 信 
Bo 

protected void noHandlerFound(HttpServletRequest request, 


3r 


HttpServletResponse response) 
throws Exception 1 
if (pageNotFoundLogger.isWarnEnabled()) 1 
String requestUri = urlPathHelper.getRequestUri(request); 
pageNotFoundLogger.warn("No mapping found for HTTP 
request with URI [" + 
requestUri + 
"] in DispatcherServlet with name "" + getServletName() + """); 


j 
response.sendError(HttpServletResponse.SC NOT FOUND); 


11.4.4 前 Handler 的 HandlerAdapter 


在 WebApplicationContext 的 初始 化 过 程 中 我 们 讨论 了 
HandlerAdapters 的 初始 化 ， 了 解 了 在 默认 情况 下 普通 的 Web 请 求 会 交 
给 SimpleControllerHandlerAdapter 去 处 理 。 下 面 我 们 以 
SimpleControllerHandlerAdapter 为 例 来 分 析 获 取 适 配器 的 逻辑 。 

protected HandlerAdapter getHandlerAdapter(Object handler) throws 
ServletException { 

for (HandlerAdapter ha : this.handlerAdapters) { 
if (logger.isTraceEnabled()) 1 
logger.trace(" Testing handler adapter [" + ha + "]"); 
j 
if (ha.supports(handler)) { 


return ha; 


j 
throw new ServletException("No adapter for handler [" + handler + 
"|: Does your handler implement a supported interface like 
Controller?"); 
} 
通过 上 面 的 消 数 我 们 了 解 到 ， 对 于 获取 适配器 的 逻辑 无 非 就 是 遍 
历 所 有 适配器 来 选择 合适 的 适配器 并 返回 它 ， 而 某 个 适配器 是 否 适用 
于 当前 的 Handler 人 逻辑 被 封装 在 具体 的 适配器 中 。 进 一 步 查 看 
SimpleControllerHandlerAdapter 中 的 supports 方 法 。 
public boolean supports(Object handler) { 
return (handler instanceof Controller); 
} 
分 析 到 这 里 ， 一 切 已 经 明了 ，SimpleControllerHandlerAdapter 就 
是 用 于 处 理 普通 的 Web 请 求 的 ， 而 且 对 于 SpringMVC 来 说 ， 我 们 会 把 


逻辑 封装 至 Controller 的 子 类 中 ， 例 如 我 们 之 前 的 引导 示例 
UserController 就 是 继承 自 AbstractController ， 而 AbstractController 实 
现 Controller 接 口 。 


11.4.5 缓存 处 理 


在 研究 Spring 对 缓存 处 理 的 功能 支持 前 ， 我 们 先 了 解 一 个 概念 : 

Last-Modified 缓 存 机 制 。 
(1) 在 客户 端 第 一 次 输入 URL 时 ， 服 务 器 端 会 返回 内 容 和 状态 码 

200， 表 示 请 求 成 功 ， 同 

时 会 添加 一 个 “Last-Modified” 的 响应 头 ， 表 示 此 文件 在 服务 器 上 
的 最 后 更 新 时 间 ， 例 如 ，“Last-Modified:Wed, 14 Mar 2012 10:22:42 
GMT” 表 示 最 后 更 新 时 间 为 (2012-03-14 10:22) o 

(2) 客户 端 第 二 次 请 求 此 URL 时 ， 客 户 端 会 向 服务 器 发 送 请 求 头 

“If-Modified-Since”， 询 问 服务 器 该 时 间 之 后 当前 请 求 内 容 是 否 有 被 修 
改过 ， 如 “If-Modified-Since: Wed, 14 Mar 2012 10:22:42 GMT”， 如 果 服 
务 器 端的 内 容 没 有 变化 ， 则 自动 返回 HTTP 304 状 态 码 〈 只 要 响应 头 ， 
内 容 为 空 ， 这 样 就 节省 了 网 络 带宽 ) o 

Spring 提供 的 对 Last-Modified 机 制 的 支持 ， 只 需要 实现 
LastModified 接 口 ， 如 下 所 示 : 

public class HelloWorldLastModifiedCacheController extends 
AbstractController implements 

LastModified { 

private long lastModified; 
protected ModelAndView 

handleRequestInternal(HttpServletRequest req, Http 


ServletResponse resp) throws Exception 1 


// 点 击 后 再 次 请 求 当 前 页 面 


resp.getWriter().write(" «a href=">this</a>"); 
return null; 


j 
public long getLastModified(HttpServletRequest request) 1 


if(lastModified == OL) { 
/第 一 次 或 者 逻辑 有 变化 的 时 候 ， 应 该 重新 返回 内 容 最 新 
修改 的 时 间 戳 
lastModified = System.currentTimeMillis(); 
} 


return lastModified; 


} 
HelloWorldLastModifiedCacheController 只 需要 实现 LastModified 接 


口 的 getLastModified 方 法 ， 保 证 当 内 容 发 生 改变 时 返回 最 新 的 修改 时 
间 即 可 。 

Spring 判断 是 否 过 期 ， 通 过 判断 请 求 的 “If-Modified-Since”* 是 否 大 
TST 当前 的 HE 法 的 时 间 惟 ， 如 果 是 ， 则 认为 

没有 修改 。 上 面 的 controller 与 普通 的 controller 并 无 太 大 差别 ， 声 明 如 

Te: 

<bean name="/helloLastModified" 
class="com.test.controller.HelloWorldLastModifiedCache&nbsp;Controller 


"/> 
11.4.6 HandlerInterceptor 的 处 理 


Servlet API 定 义 的 servlet 过 滤器 可 以 在 servlet 处 理 每 个 Web 请 求 的 
前 后 分 别 对 它 进 行 前 置 处 理 和 后 置 处 理 。 此 外 ， 有 些 时 候 ， 你 可 能 只 


想 处 理由 某 些 SpringMVC 处 理 程序 SPURS 并 在 这 些 处 理 程 
序 返回 的 模型 属性 被 传递 到 视图 之 前 ， 对 它们 进行 一 些 操作 。 
SpringMVC 人 允许 你 通过 处 理 拦截 web 请求， 进行 前 置 处 理 和 后 置 
处 理 。 处 理 拦截 是 在 Spring 的 Web 应 用 程序 上 下 文中 配置 的 ， 因 此 它们 
可 以 利用 各 种 容器 特性 ， 并 引用 容器 中 声明 的 任何 bean。 处理 拦截 是 
针对 特殊 的 处 理 程序 映射 进行 注册 的 ， 因 此 它 只 拦截 通过 这 些 处 理 程 
序 映射 的 请 求 。 每 个 处 理 拦截 都 必须 实现 HandlerInterceptor 接 口 ， 它 
包含 三 个 需 eu 的 回调 方法 : preHandle(). postHandleQAU 
afterCompletion()。 第 一 个 和 第 二 个 方法 分 别 是 在 处 理 程序 处 理 请 求 之 
前 和 之 后 被 调用 的 。 第 二 个 方法 还 允许 访问 返回 的 ModelAndView 对 
象 ， 因 此 可 以 在 它 里 面 操作 模型 属性 。 最 后 一 个 方法 是 在 所 有 请 求 处 
理 完 成 之 后 被 调用 的 〈 如 视图 呈现 之 后 ) ， 以 下 是 HandlerInterceptor 
的 简单 实现 : 
public class MyTestInterceptor implements HandlerInterceptor{ 
public boolean preHandle(HttpServletRequest request, 
HttpServletResponse response,Object handler)throws 
Exception(1 
long startTime = System.currentTimeMillis(); 
request.setAttribute( "start Time" startTime); 
return true; 
j 
public void postHandle(HttpServletRequest 
request, HttpServletResponse response, 
Object handler, ModelAndView modelAndView)throws 
Exception { 
long startTime = (Long)request.getAttribute("startTime"); 


request.removeAttribute("startTime"); 


long endTime = System.current TimeMillis(); 
modelAndView.addObject("handlingTime",endTime-startTime); 
} 
public void afterCompletion(HttpServletRequest request, 
HttpServletResponse response, Object handler, Exception 
ex)throws Exception{ 
} 

} 

在 这 个 拦截 器 的 preHandler0 方 法 中 ， 你 记录 了 起 始 时 间 ， 并 将 它 
保存 到 请 求 属性 中 。 这 个 方法 应 该 返回 true， 人 允许 DispatcherServlet 继 
续 处 理 请 求 。 否 则 ，DispatcherServlet 会 认为 这 个 方法 已 经 处 理 了 请 
求 ， 直 接 将 响应 返回 给 用 户 。 然 后 ， 在 postHandler() 方 法 中 ， 从 请 求 
属性 中 加 载 起 始 时 间 ， 并 将 它 与 当前 时 间 进 行 比较 。 你 可 以 计算 总 的 
持续 时 间 ， 然 后 把 这 个 时 间 添 加 到 模型 中 ， 传 递 给 视图 。 最 后 ， 
afterCompletion() 方 法 无 事 可 做 ， 空 着 就 可 以 了 。 


11.4.7 逻辑 处 理 


对 于 逻辑 处 理 其 实 是 通过 适配器 中 转调 用 Handler 并 返回 视图 的 ， 
对 应 代码 : 

mv = ha.handle(processedRequest, response, 
mappedHandler.getHandler()); 

同样 ， 还 是 以 引导 示例 为 基础 进行 处 理 人 逻辑 分 析 ， 之 前 分 析 过 ， 
对 于 普通 的 Web 请 求 ，Spring 默 认 使 用 SimpleControllerHandlerAdapter 
类 进行 处 理 ， 我 们 进入 SimpleControllerHandlerAdapter 类 的 handle 方 法 
如 下 : 

public ModelAndView handle(HttpServletRequest request, 


HttpServletResponse response, 


Object handler) 
throws Exception 1 
return ((Controller) handler).handleRequest(request, response); 
j 
但 是 回顾 引导 示例 中 的 UserController， 我 们 的 逻辑 是 写 在 
handleRequestInternal 芍 数 中 而 不 是 handleRequest 孜 数 ， 所 以 我 们 还 需 
要 进一步 分 析 这 期 间 所 包含 的 处 理 流 程 。 
public ModelAndView handleRequest(HttpServletRequest request, 
HttpServletResponse response) 
throws Exception 1 
// Delegate to WebContentGenerator for checking and preparing. 
checkAndPrepare(request, response, this instanceof LastModified); 
/如 果 需 要 session 内 的 同步 执行 
if (this.synchronizeOnSession) { 
HttpSession session = request.getSession(false); 
if (session !- null) { 
Object mutex = WebUtils.getSessionMutex(session); 
synchronized (mutex) { 
/调用 用 户 的 逻辑 


return handleRequestInternal(request, response); 


j 
// 调 用 用 户 逻 辑 


return handleRequestInternal(request, response); 


11.4.8 异常 视图 的 处 理 
有 时 候 系 统 运行 过 程 中 出 现 异 常 ， 而 我 们 并 不 希望 就 此 中 断 对 用 
户 的 服务 ， 而 是 至 少 告知 客户 当前 系统 在 处 理 逻 辑 的 过 程 中 出 现 了 异 
常 ， 甚 至 告知 他 们 因为 什么 原因 导致 的 。Spring 中 的 异常 处 理 机 制 会 
帮 有 我 们 完成 这 个 工作 。 其 实 ， 这 里 Spring 主要 的 工作 就 是 将 逻辑 引导 
至 HandlerExceptionResolver 类 的 resolveException 方 法 ， 而 
HandlerExceptionResolver 的 使 用 ， 我 们 在 讲解 WebApplicationContext 的 
初始 化 的 时 候 已 经 介绍 过 了 。 
protected ModelAndView 
processHandlerException(HttpServletRequest request, HttpServletResponse 
response, 
Object handler, Exception ex) throws Exception 1 
// Check registered HandlerExceptionResolvers... 
ModelAndView exMv - null; 
for (HandlerExceptionResolver handlerExceptionResolver : 


this.handlerException 
Resolvers) 1 


exMv -handlerExceptionResolver.resolveException(request, 
response, handler, ex); 
if (exMv != null) { 
break; 


} 
if (exMv != null) { 
if (ex Mv.isEmpty()) { 


return null; 


} 


// We might still need view name translation for a plain error 
model... 
if (IexMv.hasView()) 1 
exMv.setViewName(getDefaultViewName(request)); 
j 
if (logger.isDebugEnabled()) 1 
logger.debug(" Handler execution resulted in exception - 
forwarding to 
resolved error view: " + exMv, ex); 
j 
WebUtils.exposeErrorRequestAttributes(request, ex, 
getServletName()); 
return exMv; 
j 
throw ex; 


} 
11.4.9 


无 论 是 一 个 系统 还 是 一 个 站 点 ， 最 重要 的 工作 都 是 与 用 户 进行 区 
互 ， 用 户 操作 系统 后 无 论 下 发 的 命令 成 功 与 否 都 需要 给 用 户 一 个 反 
馈 ， 以 便于 用 户 进 行 下 一 步 的 判断 。 所 以 ， 在 逻辑 处 理 的 最 后 一 定 会 
涉及 一 个 页 面 跳 转 的 问题 。 

protected void render(ModelAndView mv, HttpServletRequest request, 
HttpServletResponse 


response) throws Exception 1 


// Determine locale for request and apply it to the response. 
Locale locale = this.localeResolver.resolveLocale(request); 
response.setLocale(locale); 
View view; 
if (mv.isReference()) { 

// We need to resolve the view name. 

view =resolve ViewName(mv.getViewName(), 

mv.getModelInternal(), locale, request); 
if (view == null) { 
throw new ServletException( 


"Could not resolve view with name " + mv.get ViewName() + 


in servlet with name "+ 


getServletName() + """); 


} 
else { 
// No need to lookup: the ModelAndView object contains the 
actual View object. 
view = mv.getView(); 
if (view == null) { 
throw new ServletException("ModelAndView [" + mv + "] 
neither contains 
a view name nora" + 


"View object in servlet with name " + getServletName() + """); 


// Delegate to the View object for rendering. 
if (logger.isDebugEnabled()) 1 
logger.debug(" Rendering view [" + view + "] in 
DispatcherServlet with name 
™ + getServletName() + ””); 
} 
view.render(mv.getModelInternal(), request, response); 
j 
1. 解析 视图 名 称 
在 上 文中 我 们 提 到 DispatcherServlet 会 根据 ModelAndView 选 择 合 
适 的 视图 来 进行 泻 染 ， 而 这 一 功能 就 是 在 resolveViewName 孙 数 中 完成 
的 。 
protected View resolveViewName(String viewName, Map<String, 
Object» model, Locale locale, 
HttpServletRequest request) throws Exception 1 
for (ViewResolver viewResolver : this.viewResolvers) 1 


View view = viewResolver.resolveViewName(viewName, 


locale); 
if (view != null) { 
return view; 
j 
j 
return null; 
j 
我 们 以 


org.Springframework.web.servlet.view.InternalResourceViewResolver 为 


例 来 分 析 ViewResolver 逻 辑 的 解析 过 程 ， 其 中 resolveViewName 因 数 的 
实现 是 在 其 父 类 AbstractCaching ViewResolver 中 完成 的 。 
public View resolveViewName(String viewName, Locale locale) 
throws Exception 1 
if (!isCache()) { 
/不 存在 缓存 的 情况 下 直接 创建 视图 
return createView(viewName, locale); 
j 
else { 
// 直 接 从 缓存 中 提取 
Object cacheKey = getCacheKey(viewName, locale); 
synchronized (this.viewCache) { 
View view = this.viewCache.get(cacheKey); 
if (view == null && (!this.cacheUnresolved || !this.viewCache. 
containsKey(cacheKey))) { 
// Ask the subclass to create the View object. 
view = createView(viewName, locale); 
if (view != null || this.cacheUnresolved) { 
this.viewCache.put(cacheKey, view); 
if (logger.isTraceEnabled()) { 


logger.trace("Cached view [" + cacheKey + "]"); 


} 


return view; 


j 
TE S 2SUrIBasedViewResolverFHE 5 f createViewEK] ZA, 
protected View createView(String viewName, Locale locale) throws 
Exception 1 
/如 果 当 前 解析 器 不 支持 当前 解析 器 如 viewName 为 空 等 情况 
if (!canHandle(viewName, locale)) { 
return null; 
} 
/处 理 前 缀 为 redirect:xx 的 情况 
if (viewName.startsWith(REDIRECT URL PREFIX)) { 
String redirectUrl = 
viewName.substring(REDIRECT URL PREFIX.length()); 
RedirectView view = new RedirectView(redirectUrl, 
isRedirectContext 
Relative(), isRedirectHttp10Compatible()); 
return applyLifecycleMethods(viewName, view); 
j 
/处 理 前 缀 为 forward: xx 的 情况 
if (viewName.starts With FORWARD URL PREFIX)) { 
String forwardUrl = 
viewName.substring(FORWARD URL PREFIX.length()); 
return new InternalResourceView(forwardUrl); 
l 
// Else fall back to superclass implementation: calling loadView. 


return super.create View(viewName, locale); 


protected View createView(String viewName, Locale locale) throws 


Exception 1 
return loadView(viewName, locale); 


} 


protected View loadView(String viewName, Locale locale) throws 
Exception 1 
AbstractUrlBasedView view - buildView(viewName); 
View result = applyLifecycleMethods(viewName, view); 


return (view.checkResource(locale) ? result : null); 


} 
protected AbstractUrlBasedView buildView(String viewName) throws 


Exception { 
AbstractUrlBasedView view = (AbstractUrlBasedView) 
BeanUtils.instantiateClass 
(get ViewClass()); 
/添加 前 缀 以 及 后 缀 
view.setUrl(getPrefix() + viewName + getSuffix()); 
String contentType = getContentType(); 
if (contentType != null) { 
//1 ContentType 
view.setContentType(contentType); 


} 
view.setRequestContextAttribute(getRequestContextAttribute()); 


view.setAttributesMap(getAttributesMap()); 


if (this.exposePath Variables != null) { 
view.setExposePath Variables(exposePath Variables); 


return view; 
} 
通读 以 上 代码 ， 我 们 发 现 对 于 InternalResourceViewResolver 所 提供 
的 解析 功能 主要 考虑 到 了 几 个 方面 的 处 理 。 
基于 效率 的 考虑 ， 提 供 了 缓存 的 支持 。 
提供 了 对 redirect:xx 和 forward:xx 前 缀 的 支持 。 
添加 了 前 级 及 后 经， 并 向 View 中 加 入 了 必需 的 属性 设置 。 
2. 页 面 跳 转 
当 通 过 viewName 解 析 到 对 应 的 View 后 ， 就 可 以 进一步 地 处 理 跳 转 
逻辑 了 。 
public void render(Map<String, ?> model, HttpServletRequest request, 
HttpServletResponse 
response) throws Exception 1 
if (logger.isTraceEnabled()) 1 
logger.trace("Rendering view with name " + this.beanName + ” 
with model " + model + 
" and static attributes " + this.staticAttributes); 
j 
Map<String, Object? mergedModel = 
createMergedOutputModel(model, request, 
response); 
prepareResponse(request, response); 
renderMergedOutputModel(mergedModel, request, response); 
j 
在 引导 示例 中 ， 我 们 了 解 到 对 于 ModelView 的 使 用 ， 可 以 将 一 些 
属性 直接 放 入 其 中 ， 然 后 在 页 面 上 直接 通过 JSTL 语 法 或 者 原始 的 
request 获 取 。 这 是 一 个 很 方便 也 很 神奇 的 功能 ， 但 是 实现 却 并 不 复 


杂 ， 无 非 是 把 我 们 将 要 用 到 的 属性 放 入 request 中 ， 以 便 在 其 他 地 方 可 
以 直接 调用 ， 而 解析 这 些 属性 的 工作 就 是 在 createMergedOutputModel 
PR EX PASCAL AY. 
protected Map<String, Object> 
createMergedOutputModel(Map<String, ?> model, HttpServletRequest 
request, 
HttpServletResponse response) { 
@Suppress Warnings("unchecked") 
Map<String, Object» pathVars = this.exposePathVariables ? 
(Map<String, Object>) 
request.getAttribute(View.PATH_VARIABLES) : null; 
// Consolidate static and dynamic model attributes. 
int size = this.staticAttributes.size(); 
size += (model != null) ? model.size() : 0; 
size += (pathVars != null) ? pathVars.size() : 0; 
Map<String, Object> mergedModel = new HashMap<String, Object> 
(size); 
mergedModel.putAll(this.staticAttributes); 
if (pathVars != null) { 
mergedModel.putAll(pathVars); 
} 
if (model != null) { 
mergedModel.putAll(model); 
j 
// Expose RequestContext? 
if (this.requestContextAttribute != null) 1 


mergedModel.put(this.requestContextAttribute, 
createRequestContext(request, 
response, mergedModel)); 
} 
return mergedModel; 
} 
// 处 理 页 面 跳 转 
protected void renderMergedOutputModel( 
Map<String, Object» model, HttpServletRequest request, 
HttpServletResponse 
response) throws Exception 1 
// Determine which request handle to expose to the 
RequestDispatcher. 
HttpServletRequest request ToExpose = 
getRequestToExpose(request); 
/将 model 中 的 数据 以 属性 的 方式 设置 到 request 中 
exposeModelAsRequestAttributes(model, request ToExpose); 
// Expose helpers as request attributes, if any. 
exposeHelpers(request ToExpose); 
// Determine the path for the request dispatcher. 
String dispatcherPath = prepareForRendering(requestToExpose, 
response); 
// Obtain a RequestDispatcher for the target resource (typically a 
JSP). 
RequestDispatcher rd = getRequestDispatcher(request TOExpose, 
dispatcherPath); 
if (rd == null) 1 


throw new ServletException(" Could not get RequestDispatcher 
for [" + getUrl() + 
"|: Check that the corresponding file exists within your web 
application archive!"); 
j 
// If already included or response already committed, perform 
include, else forward. 
if (useInclude(requestToExpose, response)) { 
response.setContentType(getContentType()); 
if (logger.isDebugEnabled()) { 
logger.debug("Including resource [" + getUrl() + "| in Internal 
ResourceView " + getBeanName() + """); 
j 
rd.include(requestToExpose, response); 
j 
else { 
// Note: The forwarded resource is supposed to determine the 
content type itself. 
exposeForwardRequestAttributes(request [oExpose); 
if (logger.isDebugEnabled()) 1 
logger.debug(" Forwarding to resource [" + getUrl() + "] in 
Internal ResourceView "+ getBeanName() + '""); 
1 


rd.forward(requestToExpose, response); 


12 yu 


Java 远 程 方法 调用 ， 即 Java RMI (Java Remote Method 
Invocation) ， 是 Java 编 程 语言 里 一 种 用 于 实现 远程 过 程 调用 的 应 用 程 
序 编程 接口 。 它 使 客户 机 上 运行 的 程序 可 以 调用 远程 服务 器 上 的 对 
象 。 远 程 方法 调用 特性 使 Java 编 程 人 员 能 够 在 网 络 环境 中 分 布 操作 。 
RMI 全 部 的 宗旨 就 是 尽 可 能 地 简化 远程 接口 对 象 的 使 用 。 

JavaRMI 极 大 地 依赖 于 接口 。 在 需要 创建 一 个 远程 对 象 时 ， 程 序 
员 通 过 传递 一 个 接口 来 隐藏 底层 的 实现 细节 。 客 户 端 得 到 的 远程 对 象 
句柄 正好 与 本 地 的 根 代 码 连接 ， 由 后 者 负责 透 过 网 络 通信 。 这 样 一 
来 ， 程 序 员 只 需 关 心 如 何 通过 自己 的 接口 句柄 发 送 消息 。 


12.1 RMI 


在 Spring 中 ， 同 样 提供 了 对 RMI 的 支持 ， 使 得 在 Spring 下 的 RMI 开 
变 得 更 方便 ， 同 样 ， 我 们 还 是 通过 示例 来 快速 体验 RMI 所 提供 的 功 
能 。 


以 下 提供 了 Spring 整合 RMI 的 使 用 示例 。 
(1) 建立 RMI 对 外 接口 。 
public interface HelloRMIService { 
public int getAdd(int a, int b); 
j 
(2) 建立 接口 实现 类 。 
public class HelloRMIServiceImpl implements HelloRMIService { 
public int getAdd(int a, int b) 1 


return a * b; 


} 
(3) 建立 服务 端 配置 文件 。 
<?xml version="1.0" encoding="UTF-8"?> 
«beans xmlns-"http://www.Springframework.org/schema/beans" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation=" 
http://www. Springframework.org/schema/beans 
http://www. Springframework.org/schema/beans/Spring-beans-3.0.xsd 
"> 
<!-- 服 务 端 --> 
<bean id-"helloRMIServiceImpl" 
class-"test.remote. HelloRMIServiceImpl" /> 
<!-- 将 类 为 一 个 RMI 服 务 --> 
<bean id="myRMI" 
class="org.Springframework.remoting.RMI.RMIServiceExporter"> 
<!-- 服 务 类 --> 
«property name="service" ref-"helloRMIServiceImpl" /> 
<!-- 服 务 名 --> 
«property name-"serviceName" value="helloRMI" /> 
<!-- 服 务 接口 --> 
<property name-"serviceInterface" 
value="test.remote.HelloRMIService" /> 
<!-- 服 务 端 口 --> 
<property name-"registryPort" value="9999" /> 
<!-- 其 他 属性 自己 查看 
org.Springframework.remoting.RMI.RMIServiceExporter 的 类 ,就 


知道 支持 的 属性 了 --> 
</bean> 
</beans> 
(4) 建立 服务 端 测试 。 
public class ServerTest 1 
public static void main(String[] args) 1 
new 
ClassPathXmlApplicationContext("test/remote/RMIServer.xml"); 
j 

} 

到 这 里 ， 建 立 RMI 服务 端的 步骤 已 经 结束 了 ， 服 务 端 发 布 了 一 个 
两 数 相 加 的 对 外 接口 供 其 他 服务 器 调用 。 局 动 服 务 端 测 试 类 ， 其 他 机 
器 或 端口 便 可 以 通过 RMI 来 连接 到 本 机 了 。 

(5) 完成 了 服务 端的 配置 后 ， 还 需要 在 测试 端 建立 测试 环境 以 及 
测试 代码 。 首 先 建立 测试 端 配置 文件 。 

<?xml version="1.0" encoding="UTF-8"?> 

«beans xmlns-"http://www.Springframework.org/schema/beans" 

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 

xsi:schemaLocation=" 

http://www. Springframework.org/schema/beans 

http://www. Springframework.org/schema/beans/Spring-beans-3.0.xsd 
"> 

<!-- 客 户 端 --> 
<bean id="myClient" 
class="org.Springframework.remoting.RMI.RMIProxyFactoryBean"> 
«property name-"serviceUrl" 
value="RMI://127.0.0.1:9999/helloRMI"/> 


<property name-"serviceInterface" 
value="test.remote.HelloRMIService"/> 
</bean> 
</beans> 
(6) 编写 测试 代码 。 
public class ClientTest { 
public static void main(String[] args) 1 
ApplicationContext context = new 
ClassPathXmlA pplicationContext ("test/remote/ 
RMIClient.xml"); 
HelloRMIService hms = context.getBean("myClient", 
HelloRMIService.class); 
System.out.printIn(hms.getAdd(1, 2)); 


} 

通过 以 上 的 步骤 ， 实 现 了 测试 端的 代码 调用 。 你 会 看 到 测试 端 通 
过 RMI 进 行 了 远程 连接 ， 连 接 到 了 服务 端 ， 并 使 用 对 应 的 实现 类 
HelloRMIServiceImpl 中 提供 的 方法 getAdd 来 计算 参数 并 返回 结果 ， 你 
会 看 到 控制 台 输 出 了 3。 当然 以 上 的 测试 用 例 是 使 用 同一 台 机 器 不 同 的 
端口 来 模拟 不 同 机 器 的 RMI 连 接 。 在 企业 应 用 中 一 般 都 是 使 用 不 同 的 
机 器 来 进行 RMI 服 务 的 发 布 与 访问 ， 你 需要 将 接口 打包 ， 并 放置 在 服 
务 端的 工程 中 。 

这 是 一 个 简单 的 方法 展示 ， 但 是 却 很 好 地 展示 了 Spring 中 使 用 
RMI 的 流程 以 及 步骤 ， 如 果 抛 弃 Spring 而 使 用 原始 的 RMI 发 布 与 连接 ， 
则 会 是 一 件 很 麻烦 的 事情 ， 有 兴趣 的 读者 可 以 查阅 相关 的 资料 。 在 
Spring 中 使 用 RMI 非 常 简 单 ，Spring 帮 助 我 们 做 了 大 量 的 工作 ， 这 些 工 


作 都 包括 什么 呢 ? 接 下 来 我 们 一 起 深入 分 析 Spring 中 对 RMI 功 能 的 实 
现 原理 。 


12.1.2 现 


首先 我 们 从 服务 端的 发 布 功 能 开始 着 手 ， 同 样 ，Spring 中 的 核心 
还 是 配置 文件 ， 这 是 所 有 功能 的 基础 。 在 服务 端的 配置 文件 中 我 们 可 
以 看 到 ， 定 义 了 两 个 bean， 其 中 一 个 是 对 接口 实现 类 的 发 布 ， 而 另 一 
个 则 是 对 RMI 服 务 的 发 布 ， 使 用 
org.Springframework.remoting.RMI.RMIServiceExporter 类 进行 封装 ， 其 
中 包括 了 服务 类 、 服 务 名 、 服 务 接 口 、 服 务 端 口 等 若干 属性 ， 因 此 我 
们 可 以 断定 ， org.Springframework.remoting.RMI.RMIServiceExporter 
类 应 该 是 发 布 RMI 的 关键 类 。 我 们 可 以 从 此 类 入 手 进 行 分 析 。 

根据 前 面 展示 的 示例 ， 启 动 Spring 中 的 RMI 服 务 并 没有 多 余 的 操 
作 ， 仅 仅 是 开启 Spring 的 环境 : new 
ClassPathXmlA pplicationContext("test/remote/RMIServer.xml"), {Xitb— 
句 。 于 是 ， 我 们 分 析 很 可 能 是 RMIServiceExportern 在 初始 化 的 时 候 做 
了 某 些 操作 完成 了 端口 的 发 布 功能 ， 那 么 这 些 操作 的 入 口 是 在 这 个 类 
的 哪个 方法 里 面 呢 ? 

进入 这 个 类 ， 首 先 分 析 这 个 类 的 层次 结构 ， 如 图 12-1 所 示 。 


ti EB 
4 K9 RmiServiceExporter 
4 (9^ RmiBasedExporter 
4 (9^ RemotelnvocationB asedExporter 
4 (9^ RemoteExporter 
4 (9^ RemotingSupport 
© Object 
4 © BeanClassLoaderAware 
Q Aware 
© DisposableBean 
© InitializingBean 


图 12-1 RMIServiceExporter 类 层次 结构 图 


根据 Eclipse 提供 的 功能 ， 我 们 查看 到 了 RMIServiceExporter 的 层次 
结构 图 ， 那 么 从 这 个 层次 图 中 我 们 能 得 到 什么 信息 呢 ? 
RMIServiceExporter 实现 了 Spring 中 几 个 比较 敏感 的 接口 : 
BeanClassLoaderAware、DisposableBean、InitializingBean， 其 中 ， 
DisposableBean 接 口 保证 在 实现 该 接口 的 bpean 销 毁 时 调用 其 destroy 方 
法 ，BeanClassLoaderAware 接 口 保 证 在 实现 该 接口 的 bean 的 初始 化 时 调 
用 其 setBeanClassLoader 方 法 ， 而 InitializingBean 接 口 则 是 保证 在 实现 
该 接口 的 bean 初 始 化 时 调用 其 afterPropertiesSet 方法 ， 所 以 我 们 推断 
RMIServiceExporter 的 初始 化 函数 入 口 一 定 在 其 afterPropertiesSet 或 者 
setBeanClassLoader 方法 中 。 经 过 查看 代码 ， 确 认 afterPropertiesSet 为 
RMIServiceExporter 功 能 的 初始 化 入 口 。 
public void afterPropertiesSet() throws RemoteException { 
prepare(); 
j 
public void prepare() throws RemoteException 1 
/检查 验证 service 
checkService(); 
if (this.serviceName == null) 1 
throw new IllegalArgumentException(" Property 'serviceName' is 
required"); 
} 
/如 果 用 户 在 配置 文件 中 配置 了 clientSocketFactory 或 者 
serverSocketFactory 的 处 理 
p 


* 如 果 配 置 中 的 clientSocketFactory 同 时 又 实现 了 
RMIServerSocketFactory 接 口 那么 会 忽略 
* 配置 中 的 serverSocketFactory 而 使 用 clientSocketFactory 代 替 
"i 
if (this.clientSocketFactory instanceof RMIServerSocketFactory) { 
this.serverSocketFactory = (RMIServerSocketFactory) 
this.clientSocketFactory; 
} 
//clientSocketFactory#llserverSocketFactory 2A [AJAY Hi 8 ZA BB 
不 出 现 
if ((this.clientSocketFactory != null && this.serverSocketFactory 
== null) || 
(this.clientSocketFactory == null && this.serverSocketFactory != 
null)) { 
throw new IllegalArgumentException( 
"Both RMIClientSocketFactory and RMIServerSocketFactory or 
none 


required"); 


* 如 果 配 置 中 的 registryClientSocketFactory 同 时 实现 了 
RMIServerSocketFactory 接 口 那 么 
* 会 忽略 配置 中 的 registryServerSocketFactory 而 使 用 
registryClientSocketFactory{t® 
*/ 
if (this.registryClientSocketFactory instanceof 


RMIServerSocketFactory) { 


this.registryServerSocketFactory = (RMIServerSocketFactory) 
this.registry 
ClientSocketFactory; 

} 

/不 允许 出 现 只 配置 registryServerSocketFactory 却 没有 配置 
registryClientSocketFactory 的 
青 况 出 现 

if (this.registryClientSocketFactory == null && 
this.registryServerSocket 


H 


Factory != null) { 
throw new IllegalArgumentException( 
"RMIServerSocketFactory without RMIClientSocketFactory for 


registry not supported"); 
} 
this.createdRegistry = false; 
/确定 RMI registry 
if (this.registry == null) { 
this.registry = getRegistry(this.registryHost, this.registryPort, 
this.registryClientSocketFactory, 
this.registryServerSocketFactory); 


this.createdRegistry = true; 


} 
/初始 化 以 及 缓存 导出 的 Object 
// 此 时 通常 情况 下 是 使 用 RMIInvocationWrapper 封 装 的 JDK 代 理 


类 ， 切 面 为 RemoteInvocation 


TraceInterceptor 


this.exportedObject = getObjectToExport(); 


if (logger.isInfoEnabled()) 1 
logger.info(" Binding service ™ + this.serviceName + " to RMI 
registry: " 
* this.registry); 
j 
// Export RMI object. 
if (this.clientSocketFactory !- null) 1 
[* 
* 使 用 由 给 定 的 套 接 字 工厂 指定 的 传送 方式 导出 远程 对 
象 ， 以 便 能 够 接收 传 入 的 调用 。 
* ClientSocketFactory: 进 行 远 程 对 象 调用 的 客户 端 套 接 字 工 
m 
* serverSocketFactory: ZM a ys FH AYERS Vm BRS IL] 
*/ 
UnicastRemoteObject.exportObject( 
this.exportedObject, this.servicePort, this.clientSocketFactory, 
this.serverSocketFactory); 
j 
else { 
/导出 remote object, 以 使 它 能 接收 特定 端口 的 调用 
UnicastRemoteObject.exportObject(this.exportedObject, 
this.servicePort); 
j 
try { 
if (this.replaceExistingBinding) { 
this.registry.rebind(this.serviceName, this.exportedObject); 


else { 


/ 绑 定 服务 名 称 到 remote object， 外 界 调用 serviceName 的 
时 候 会 被 exportedObject 


接收 


this.registry.bind(this.serviceName, this.exportedObject); 


} 

catch (AlreadyBoundException ex) { 
unexportObjectSilently(); 
throw new IllegalStateException( 


"Already an RMI object bound for name '" + this.serviceName + 


"+ ex.toString()); 
} 
catch (RemoteException ex) { 


unexportObjectSilently(); 


throw ex; 


} 


果然 ， 在 afterPropertiesSet 国 数 中 将 实现 委托 给 了 prepare， 而 在 
prepare 方 法 中 我 们 找到 了 RMI 服 务 发 布 的 功能 实现 ， 同 时 ， 我 们 也 大 
致 清楚 了 RMI 服 务 发 布 的 流程 。 


(1) 验证 serviceo 

此 处 的 service 对 应 的 是 配置 中 类 型 为 RMIServiceExporter 的 service 
属性 ， 它 是 实现 类 ， 并 不 是 接口 。 尽 管 后 期 会 对 RMIServiceExporter 做 
一 系列 的 封装 ， 但 是 ， 无 论 和 坊 么 封装 ， 最 终 还 是 会 将 逻辑 引 向 至 


RMIServiceExporter 来 处 理 ， 所 以 ， 在 发 布 之 前 需要 进行 验证 。 


(2) 处 理 用 户 自 定义 的 SocketFactory 属 性 。 

在 RMIServiceExporter 中 提供 了 4 个 套 接 字 工厂 配置 ， 分 别 是 
clientSocketFactory、 serverSocket Factory 和 
registryClientSocketFactory、registryServerSocketFactory。 那 么 这 两 对 
配置 又 有 什么 区 别 或 者 说 分 别 是 应 用 在 什么 样 的 不 同 场景 呢 ? 

registryClientSocketFactory 与 registryServerSocketFactory 用 于 主机 
与 RMI 服 务 器 之 间 连 接 的 创建 ， 也 就 是 当 使 用 
LocateRegistry.createRegistry(registryPort, clientSocketFactory, server 
SocketFactory) 方 法 创建 Registry 实 例 时 会 在 RMI 主 机 使 用 
serverSocketFactory 创 建 套 接 字 等 待 连接 ， 而 服务 端 与 RMI 主 机 通信 时 
会 使 用 clientSocketFactory 创 建 连 接 套 接 字 。 

clientSocketFactory、 serverSocketFactory 同样 是 创建 套 接 字 ， 但 是 
使 用 的 位 置 不 同 ， clientSocketFactory、serverSocketFactory 用 于 导出 远 
程 对 象 ，serverSocketFactory 用 于 在 服务 端 建 立 套 接 字 等 待 客户 端 连 
接 ， 而 clientSocketFactory 用 于 调用 端 建立 套 接 字 发 起 连接 。 

(3) 根据 配置 参数 获取 Registry。 
(4) 构造 对 外 发 布 的 实例 。 

构建 对 外 发 布 的 实例 ， 当 外 界 通 过 注册 的 服务 名 调用 响应 的 方法 

时 ，RMI 服 务 会 将 请 求 引 入 此 类 来 处 理 。 
(5) 发 布 实例 。 

在 发 布 RMI 服 务 的 流程 中 ， 有 几 个 步骤 可 能 是 我 们 比较 关心 的 。 

1。 获 取 registry 

对 RMI 稍 有 了 解 就 会 知道 ， 由 于 底层 的 封装 ， 获 取 Registry 实 例 是 
非 音 简单 的 ， 只 需要 使 用 一 个 图 数 LocateRegistry.createRegistry(...) 创 建 
Registry 实 例 就 可 以 了 。 但 是 ，Spring 中 并 没有 这 么 做 ， 而 是 考虑 得 更 
多 ， 比 如 RMI 注册 主机 与 发 布 的 服务 并 不 在 一 台 机 器 上 ， 那 么 需要 使 


用 LocateRegistry.getRegistry(registryHost, registryPort, 
clientSocketFactory) 去 远程 获取 Registry 实 例 。 
protected Registry getRegistry(String registryHost, int registryPort, 
RMIClientSocketFactory clientSocketFactory, 
RMIServerSocketFactory 
serverSocketFactory) 
throws RemoteException 1 
if (registryHost != null) { 
/远程 连接 测试 
if (logger.isInfoEnabled()) { 
logger.info("Looking for RMI registry at port "" + registryPort 


ym 
of host [" + registryHost + "]"); 
} 
/如 果 registryHost 不 为 空 则 党 试 获取 对 应 主机 的 Registry 
Registry reg = LocateRegistry.getRegistry(registryHost, 
registry Port, 


clientSocketFactory); 
testRegistry(reg); 
return reg; 
yelse { 
/获取 本 机 的 Registry 
return getRegistry(registryPort, clientSocketFactory, 
serverSocketFactory); 


} 


如 果 并 不 是 从 另外 的 服务 器 上 获取 Registry 连 接 ， 那 么 就 需要 在 本 
地 创建 RMI 的 Registry 实 例 了 。 当 然 ， 这 里 有 一 个 关键 的 参数 
alwaysCreateRegistry， 如 果 此 参数 配置 为 tue， 那 么 在 获取 Registry 实 
例 时 会 首先 测试 是 否 已 经 建立 了 对 指定 端口 的 连接 ， 如 果 已 经 建立 则 
复 用 已 经 创建 的 实例 ， 否 则 重新 创建 。 
当然 ， 之 前 也 提 到 过 ， 创建 Registry 实 例 时 可 以 使 用 自 定义 的 连接 
工厂 ， 而 之 前 的 判断 也 保证 了 clientSocketFactory 与 serverSocketFactory 
要 么 同时 出 现 ， 要 么 同时 不 出 现 ， 所 以 这 里 只 对 clientSocketFactory 是 
否 为 空 进行 了 判断 。 
protected Registry getRegistry( 
int registryPort, RMIClientSocketFactory clientSocketFactory, 
RMIServerSocketFactory 
serverSocketFactory) 
throws RemoteException 1 
if (clientSocketFactory != null) 1 
if (this.alwaysCreateRegistry) 1 
logger.info("Creating new RMI registry"); 
/使 用 clientSocketFactory 创 建 Registry 
serverSocketFactory); 
return LocateRegistry.createRegistry(registryPort, 
clientSocketFactory, 
j 
if (logger.isInfoEnabled()) { 
logger.info("Looking for RMI registry at port "" + registryPort 
T s 


using custom socket factory"); 


synchronized (LocateRegistry.class) { 
try { 
N/R Foo 
Registry reg = LocateRegistry.getRegistry(null, registryPort, 
clientSocketFactory); 
testRegistry(reg); 
return reg; 
} 
catch (RemoteException ex) { 
logger.debug("RMI registry access threw exception", ex); 
logger.info("Could not detect RMI registry - creating new 
one"); 
return LocateRegistry.createRegistry(registryPort, 
clientSocketFactory, 


serverSocketFactory); 


} 
jelse 1 
return getRegistry(registryPort); 


j 

如 果 创 建 Registry 实例 时 不 需要 使 用 自 定义 的 套 接 字 工厂 ， 那 么 
就 可 以 直接 使 用 LocateRegistry.createRegistry(...) 方 法 来 创建 了 ， 当 然 复 
用 的 检测 还 是 必要 的 。 

protected Registry getRegistry(int registryPort) throws 
RemoteException 1 


if (this.alwaysCreateRegistry) 1 


logger.info("Creating new RMI registry"); 
return LocateRegistry.createRegistry(registryPort); 
i 
if (logger.isInfoEnabled()) 1 
logger.info("Looking for RMI registry at port "" + registryPort + 


Wn. 
, 


synchronized (LocateRegistry.class) { 
try { 
/查看 对 应 当前 registryPort 的 Registry 是 否 已 经 创建 ， 如 果 
创建 直接 使 用 
Registry reg = LocateRegistry.getRegistry(registry Port); 
/测试 是 否 可 用 ， 如 果 不 可 用 则 抛 出 异 单 
testRegistry(reg); 
return reg; 
j 
catch (RemoteException ex) 1 
logger.debug(""RMI registry access threw exception", ex); 
logger.info("Could not detect RMI registry - creating new 
one"); 
// 根 据 端 口 创建 Registry 
return LocateRegistry.createRegistry(registryPort); 


} 
2. 初始 化 将 要 导出 的 实体 对 象 


之 前 有 提 到 过 ， 当 请 求 某 个 RMI 服 务 的 时 候 ，RMI 会 根据 注册 的 
服务 名 称 ， 将 请 求 引导 至 远程 对 象 处 理 类 中 ， 这 个 处 理 类 便 是 使 用 
getObjectToExport() 进 行 创建 。 

protected Remote getObjectToExport() { 

/如 果 配 置 的 service 属 性 对 应 的 类 实现 了 Remote 接 口 且 没 有 配置 
serviceInterface 属 性 
if (getService() instanceof Remote && 
(getServiceInterface() == null || Remote.class.isAssignableFrom 
(getServiceInterface()))) { 
return (Remote) getService(); 
j 
else { 
if (logger.isDebugEnabled()) 1 
logger.debug(""RMI service [" + getService() + "] is an RMI 
invoker"); 
j 
/对 service 进 行 封装 


return new RMIInvocationWrapper(getProxyForService(), this); 


} 

请 求 处 理 类 的 初始 化 主要 处 理 规 则 为 : 如 果 配 置 的 service 属 性 对 
应 的 类 实现 了 Remote 接 口 且 没有 配置 serviceInterface 属性 ， 那 么 直接 
使 用 service 作为 处 理 类 ; 否则 ， 使 用 RMIInvocationWrapper 对 service 
的 代理 类 和 当前 类 也 就 是 RMIServiceExporter 进 行 封装 。 

经 过 这 样 的 封装 ， 客 户 端 与 服务 端 便 可 以 达成 一 致 协议 ， 当 客户 
端 检测 到 是 RMIInvocation Wrapper 类 型 stub 的 时 候 便 会 直接 调用 其 
invoke 方 法 ， 使 得 调用 端 与 服务 端 很 好 地 连接 在 了 一 起 。 而 


RMIInvocationWrapper 封条 了 用 于 处 理 请 求 的 代理 类 ， 在 invoke 中 便 
会 使 用 代理 类 进行 进一步 处 理 。 

之 前 的 逻辑 已 经 非常 清楚 了 ， 当 请 求 RMI 服 务 时 会 由 注册 表 
Registry 实 例 将 请 求 转向 之 前 注册 的 处 理 类 去 处 理 ， 也 就 是 之 前 封装 的 
RMIInvocationWrapper， 然 后 由 RMIInvocationWrapper 中 的 invoke 方 法 
进行 处 理 ， 那 么 为 什么 不 是 在 invoke 方 法 中 直接 使 用 service， 而 是 通 
过 代理 再 次 将 service 封 狼 呢 ? 

这 其 中 的 一 个 关键 点 是 ， 在 创建 代理 时 添加 了 一 个 增强 拦截 器 
RemoteInvocationTraceInterceptor， 目 的 是 为 了 对 方法 调用 进行 打印 跟 
踪 ， 但 是 如 果 直 接 在 invoke 方法 中 硬 编 码 这 些 日 志 ， 会 使 代码 看 起 来 
很 不 优雅 ， 而 且 耦 合 度 很 高 ， 使 用 代理 的 方式 就 会 解决 这 样 的 问题 ， 
而 且 会 有 很 高 的 可 扩展 性 。 

protected Object getProxyForService() 1 

/验证 service 
checkService(); 
/验证 serviceInterface 
checkServiceInterface(); 
/使 用 JDK 的 方式 创建 代理 
ProxyFactory proxyFactory = new ProxyFactory(); 
/添加 代理 接口 
proxyFactory.addInterface(getServiceInterface()); 
if (this.registerTraceInterceptor != null ? 
this.registerTraceInterceptor.booleanValue() : this.interceptors == 
null) { 
/加 入 代理 的 横 切面 RemoteInvocationTraceInterceptor 并 记录 
Exporter 名 称 
proxyFactory.addAdvice(new 


RemoteInvocation TraceInterceptor(getExporterNamer())); 
} 
if (this.interceptors != null) { 
AdvisorAdapterRegistry adapterRegistry = 
GlobalAdvisorAdapterRegistry. 
getInstance(); 


for (int i = 0; i < this.interceptors.length; i++) { 


proxyFactory.addAdvisor(adapterRegistry.wrap(this.interceptors[i])); 
} 
} 
/设置 要 代理 的 目标 类 
proxyFactory.setTarget(getService()); 
proxyFactory.setOpaque(true); 
/创建 代理 
return proxyFactory.getProxy(getBeanClassLoader()); 
j 
3. RMI 服 务 激活 调用 
之 前 反复 提 到 过 ， 由 于 在 之 前 bean 初始 化 的 时 候 做 了 服务 名 称 绑 
定 this.registry.bind aue serviceName, this.exportedObject)， 其 中 的 
exportedObject 其 实 是 被 RMIInvocationWrapper 进 行 过 封装 的 ， 也 就 是 
说 当 人 serviceName 的 RMI 服 务 时 ，Java 会 为 我 们 封装 其 
内 部 操作 ， 而 直接 会 将 代码 转向 RMIInvocationWrapper 的 invoke 方 法 
中 。 
public Object invoke(RemoteInvocation invocation) 
throws RemoteException, NoSuchMethodException, 


IllegalAccessException, 


InvocationTargetException 1 
return this.RMIExporter.invoke(invocation, this. wrappedObject); 
j 
而 此 时 this.RMIExporter 为 之 前 初始 化 的 RMIServiceExporter， 
invocation 为 包含 着 需要 激活 的 方法 参数 ， 而 wrappedObject 则 是 之 前 封 
妆 的 代理 类 。 
protected Object invoke(RemoteInvocation invocation, Object 
targetObject) 
throws NoSuchMethodException, Illegal AccessException, 
InvocationTargetException 1 
return super.invoke(invocation, targetObject); 
j 
protected Object invoke(RemoteInvocation invocation, Object 
targetObject) 
throws NoSuchMethodException, Illegal AccessException, 
InvocationTargetException 1 
if (logger.isTraceEnabled()) { 
logger.trace(" Executing " + invocation); 
} 
try { 
return getRemoteInvocationExecutor().invoke(invocation, 
targetObject); 
} 
catch (NoSuchMethodException ex) { 
if (logger.isDebugEnabled()) { 
logger.warn(" Could not find target method for " + invocation, 


ex); 


j 
throw ex; 
i 
catch (IllegalAccessException ex) { 
if (logger.isDebugEnabled()) { 
logger.warn(" Could not access target method for " + 
invocation, ex); 
j 
throw ex; 
j 
catch (InvocationTargetException ex) { 
if (logger.isDebugEnabled()) 1 
logger.debug(" Target method failed for " + invocation, 
ex.getTargetException()); 
j 


throw ex; 


} 
public Object invoke(RemoteInvocation invocation, Object 
targetObject) 
throws NoSuchMethodException, IllegalAccessException, 
InvocationTargetException{ 
Assert.notNull(invocation, "RemoteInvocation must not be null"); 
Assert.notNull(targetObject, "Target object must not be null"); 
/通过 反射 方式 激活 方法 


return invocation.invoke(targetObject); 


public Object invoke(Object targetObject) 
throws NoSuchMethodException, Illegal AccessException, 
InvocationTarget 
Exception 1 
/根据 方法 名 称 获 取代 理 中 对 应 的 方法 
Method method = 
targetObject.getClass().getMethod(this.methodName, this. 
parameterTypes); 
/执行 代理 中 的 方法 
return method.invoke(targetObject, this.arguments); 


} 
12.1.3 现 


根据 客户 端 配置 文件 ， 锁 定 入 口 类 为 RMIProxyFactoryBean， 同 
样 根 据 类 的 层次 结构 查找 入 口 函数 ， 如 图 12-2 所 示 。 
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12-2 RMIProxyFactoryBean 类 的 层次 结构 


根据 层次 关系 以 及 之 前 的 分 析 ， 我 们 提取 出 该 类 实现 的 比较 重要 
的 接口 InitializingBean、BeanClassLoaderAware 以 及 
MethodInterceptoro 

其 中 实现 了 InitializingBean， 则 Spring 会 确保 在 此 初始 化 bean 时 调 
用 afterPropertiesSet 进 行 逻 辑 的 初始 化 。 

public void afterPropertiesSet() { 


super.afterPropertiesSet(); 
if (getServiceInterface() == null) { 


throw new IllegalArgumentException(" Property 


'serviceInterface' is 


required"); 


/根据 设置 的 接口 创建 代理 ， 并 使 用 当前 类 this 作 为 增强 器 

this.serviceProxy = new ProxyFactory(getServiceInterface()， 
this).getProxy 

(getBeanClassLoader()); 

j 

同时 ，RMIProxyFactoryBean 又 实现 了 FactoryBean 接 口 ， 那 么 当 获 
取 bean 时 并 不 是 直接 获取 bean， 而 是 获取 该 bean 的 getObject 方 法 。 

public Object getObject() 1 

return this.serviceProxy; 

} 

这 样 ， 我 们 似乎 已 近 形 成 了 一 个 大 致 的 轮廓 ， 当 获取 该 bean 时 ， 
首先 通过 afterPropertiesSet 创 建 代 理 类 ， 并 使 用 当前 类 作为 增强 方法 ， 
而 在 调用 该 bean 时 其 实 返 回 的 是 代理 类 ， 既 然 调用 的 是 代理 类 ， 那 么 
又 会 使 用 当前 bean 作为 增强 器 进行 增强 ， 也 就 是 说 会 调用 
RMIProxyFactoryBean 的 父 类 RMIClientInterceptor 的 invoke 方 法 。 

我 们 先 从 afterPropertiesSet 中 的 super.afterPropertiesSet() 方 法 开始 分 
析 。 

public void afterPropertiesSet() { 

super.afterPropertiesSet(); 
prepare(); 

j 

继续 追踪 代码 ， 发 现 父 类 的 父 类 ， 也 就 是 
UrlBasedRemoteAccessor 中 的 afterPropertiesSet 方 法 只 完成 了 对 
serviceUrl 属 性 的 验证 。 

public void afterPropertiesSet() { 

if (getServiceUrl() == null) { 


throw new IllegalArgumentException(" Property 'serviceUrl' is 


required"); 


j 
j 
所 以 推断 所 有 的 客户 端 都 应 该 在 prepare 方 法 中 实现 ， 继 续 查 看 
prepare()o 


1. 通过 代理 拦截 并 获取 stub 
在 父 类 的 afterPropertiesSet 方 法 中 完成 了 对 serviceUn 的 验证 ， 那 么 
prepare 国 数 又 完成 了 什么 功能 呢 ? 
public void prepare() throws RemoteLookupFailureException 1 
// Cache RMI stub on initialization? 
/如 果 配 置 了 lookupStubOnStartup 属 性 便 会 在 启动 时 寻找 stub 
if (this.lookupStubOnStartup) 1 
Remote remoteObj = lookupStub(); 
if (logger.isDebugEnabled()) 1 
if (remoteObj instanceof RMIInvocationHandler) { 
logger.debug("RMI stub [" + getServiceUrl() + "] is an RMI 
invoker"); 
} 
else if (getServiceInterface() != null) { 
boolean isImpl = 
getServiceInterface().isInstance(remoteObj); 
logger.debug(" Using service interface [" + 
getServiceInterface(). 
getName() + 
"| for RMI stub [" + getServiceUrl() + "] - " + 


(lisImpl ? "not " : "") + "directly implemented"); 


} 

if (this.cacheStub) { 
/将 获取 的 stub 缓 存 
this.cachedStub = remoteObj; 


j 
从 上 面 的 代码 中 ， 我 们 了 解 到 了 一 个 很 重要 的 属性 
lookupStubOnStartup ， 如 果 将 此 属性 设置 为 tue， 那 么 获取 stub 的 工作 
就 会 在 系统 启动 时 被 执行 并 缓存 ， 从 而 提高 使 用 时 候 的 响应 时 间 。 
获取 stub 是 RMI 应 用 中 的 关键 步 又， 当然 你 可 以 使 用 两 种 方式 进 
{To 
(1) 使 用 自 定义 的 套 接 字 工矿。 如果 使 用 这 种 方式 ， 你 需要 在 构 
造 Registry 实例 时 将 自 定 义 套 接 字 工厂 传 入 ， 并 使 用 Registry 中 提供 的 
lookup 方 法 来 获取 对 应 的 stub。 
(2) 直接 使 用 RMI 提 供 的 标准 方法 : 
Naming.lookup(getServiceUrl())o 
protected Remote lookupStub() throws 
RemoteLookupFailureException { 
try { 
Remote stub = null; 
if (this.registryClientSocketFactory != null) { 
URL url = new URL(null, getServiceUrl(), new 
DummyURLStreamHandler()); 
String protocol = url.getProtocol(); 


/验证 传输 协议 


if (protocol != null && !"RMI".equals(protocol)) { 
throw new MalformedURLException(" Invalid URL scheme 
"+ protocol + ™™); 
j 
/主机 
String host = url.getHost(); 
/端口 
int port = url.getPort(); 
/服务 名 
String name = url.getPath(); 
if (name != null && name.startsWith("/")) { 
name - name.substring(1); 
j 
Registry registry = LocateRegistry.getRegistry(host, port, 
this.registry 
Client SocketFactory); 
stub = registry.lookup(name); 
j 
else { 
// Can proceed with standard RMI lookup API... 
stub = Naming.lookup(getServiceUrl()); 
j 
if (logger.isDebugEnabled()) 1 
logger.debug("Located RMI stub with URL [" + 
getServiceUrl() + "]"); 
} 


return stub; 


j 
catch (MalformedURLException ex) { 
throw new RemoteLookupFailureException("Service URL [" + 
getServiceUrl() + 
"] is invalid", ex); 
j 
catch (NotBoundException ex) 1 
throw new RemoteLookupFailureException( 
"Could not find RMI service [" + getServiceUrl() + "] in RMI 
registry", ex); 
i 
catch (RemoteException ex) { 
throw new RemoteLookupFailureException("Lookup of RMI 
stub failed", ex); 
j 

j 

为 了 使 用 registryClientSocketFactory， 代 码 量 比 使 用 RMI 标 准 获取 
stub 方 法 多 出 了 很 多 ， 那 么 registryClientSocketFactory 到 底 是 做 什么 用 
的 呢 ? 

与 之 前 服务 端的 套 接 字 工厂 类 似 ， 这 里 的 
registryClientSocketFactory 用 来 连接 RMI 服 务 器 ， 用 户 通过 实现 
RMIClientSocketFactory 接 口 来 控制 用 于 连接 的 socket 的 各 种 参数 。 

2. 增强 器 进行 远程 连接 

之 前 分 析 了 类 型 为 RMIProxyFactoryBean 的 bean 的 初始 化 中 完成 的 
逻辑 操作 。 在 初始 化 时 ,创建 了 代理 并 将 本 身 作 为 增强 器 加 入 了 代理 
rH (RMIProxyFactoryBean 间接 实现 了 MethodInterceptor) 。 那 么 这 样 


一 来 ， 当 在 客户 端 调 用 代理 的 接口 中 的 某 个 方法 时 ， 就 会 首先 执行 
RMIProxyFactoryBean 中 的 invoke 方 法 进行 增强 。 


public Object invoke(MethodInvocation invocation) throws Throwable 


/获取 的 服务 器 中 对 应 的 注册 的 remote 对 象 ， 通 过 序列 化 传输 
Remote stub = getStub(); 
try { 
return doInvoke(invocation, stub); 
j 
catch (RemoteConnectFailureException ex) 1 
return handleRemoteConnectFailure(invocation, ex); 
j 
catch (RemoteException ex) 1 
if (isConnectFailure(ex)) 1 
return handleRemoteConnectFailure(invocation, ex); 
j 
else { 


throw ex; 


j 
众所周知 ， 当 客户 端 使 用 接口 进行 方法 调用 时 是 通过 RMI 获 取 
stub 的 ， 然 后 再 通过 stub 中 封装 的 信息 进行 服务 器 的 调用 ， 这 个 stub 就 
是 在 构建 服务 器 时 发 布 的 对 象 ， 那 么 ， 客 户 端 调用 时 最 关键 的 一 步 也 
是 进行 stub 的 获取 了 。 
protected Remote getStub() throws RemoteLookupFailureException 1 


if (!this.cacheStub || (this.lookupStubOnStartup && 
!this.refreshStubOnConnect 
Failure)) { 


(RBA EUER FH ZEE 
return (this.cachedStub !- null ? this.cachedStub : lookupStub()); 
j 
else { 


synchronized (this.stubMonitor) 1 
if (this.cachedStub == null) { 
|f BXstub 
this.cachedStub = lookupStub(); 
j 


return this.cachedStub; 


} 

当 获 取 到 stub 后 便 可 以 进行 远程 方法 的 调用 了 。 Spring 中 对 于 远程 
方法 的 调用 其 实 是 分 两 种 情况 考虑 的 。 

获取 的 stub 是 RMIInvocationHandler 类 型 的 ， 从 服务 端 获取 的 stub 
是 RMIInvocation Handler， 就 意味 着 服务 端 也 同样 使 用 了 Spring 去 构 
建 ， 那 么 自然 会 使 用 Spring 中 作 的 约定 ， 进 行 客户 端 调用 处 理 。 
Spring 中 的 处 理 方式 被 委托 给 了 doInvoke 方 法 。 

当 获 取 的 stub 不 是 RMIInvocationHandler 类 型 ， 那 么 服务 端 构建 
RMI 服 务 可 能 是 通过 普通 的 方法 或 者 借助 于 Spring 外 的 第 三 方 插件 ， 
那么 处 理 方式 自然 会 按照 RMI 中 普通 的 处 理 方 式 进 行 ， 而 这 种 普通 的 
处 理 方式 无 非 是 反射 。 因 为 在 invocation 中 包含 了 所 需要 调用 的 方法 


的 各 种 信息 ， 包 括 方法 名 称 以 及 参数 等 ， 而 调用 的 实体 正 是 sub， 那 
么 通过 反射 方法 完全 可 以 激活 stub 中 的 远程 调用 。 
protected Object doInvoke(MethodInvocation invocation, Remote 
stub) throws Throwable 1 
//stub 从 服务 器 传 回 且 经 过 Spring 的 封装 
if (stub instanceof RMIInvocationHandler) { 
try { 
return doInvoke(invocation, (RMIInvocationHandler) stub); 
j 
catch (RemoteException ex) 1 
throw 
RMIClientInterceptorUtils.convertrRMIAccessException( 
invocation.getMethod(), ex, isConnectFailure(ex), 
getServiceUrl()); 
} 
catch (InvocationTargetException ex) { 


Throwable exToThrow = ex.getTargetException(); 


RemotelInvocationUtils.fillInClientStackTracelIfPossible(exToThrow); 
throw exToThrow; 
} 
catch (Throwable ex) { 
throw new RemoteInvocationFailureException(" Invocation of 
method [" + 
invocation.getMethod() + 
"] failed in RMI service [" + getServiceUrl() + "|", ex); 


} 


j 
else { 
try 1 
/直接 使 用 反射 方法 继续 激活 
return 
RMIClientInterceptorUtils.invokeRemoteMethod(invocation, stub); 
j 
catch (InvocationTargetException ex) 1 
Throwable targetEx = ex.getTargetException(); 
if (targetEx instanceof RemoteException) 1 
RemoteException rex = (RemoteException) targetEx; 
throw 
RMIClientInterceptorUtils.convertRMIAccessException( 
invocation.getMethod(), rex, isConnectFailure(rex), 
getServiceUrl()); 
j 
else { 


throw targetEx; 


} 

之 前 反复 提 到 了 Spring 中 的 客户 端 处 理 RMI 的 方式 。 其 实 ， 在 分 
析 服 务 端 发 布 RMI 的 方式 时 ， 我 们 已 经 了 解 到 ，Spring 将 RMI 的 导出 
Object 封装 成 了 RMIInvocationHandler 类 型 进行 发 布 ， 那 么 当 客 户 端 获 
取 stub 的 时 候 是 包含 了 远程 连接 信息 代理 类 的 RMIInvocationHandler， 
也 就 是 说 当 调用 RMIInvocationHandler 中 的 方法 时 会 使 用 RMI 中 提供 的 


代理 进行 远程 连接 ， 而 此 时 ，Spring 中 要 做 的 就 是 将 代码 引 向 
RMIInvocationHandler 接 口 的 invoke 方 法 的 调用 。 
protected Object doInvoke(MethodInvocation methodInvocation, 
RMIInvocationHandler 
invocationHandler) 
throws RemoteException, NoSuchMethodException, 
IllegalAccessException, Invocation 
TargetException 1 
if (AopUtils.isToStringMethod(methodInvocation.getMethod())) 1 
return "RMI invoker proxy for service URL [" + getServiceUrl() 
+ 中" 
/将 methodInvocation 中 的 方法 名 及 参数 等 信息 重新 封装 到 
RemoteInvocation， 并 通过 远程 代理 
方法 直接 调用 
return 
invocationHandler.invoke(createRemoteInvocation(methodInvocation)); 


} 


12.2 HttpInvoker 


Spring 开发 小 组 意识 到 在 RMI 服 务 和 基于 HTTP 的 服务 (如 Hessian 
和 Burlap) 之 间 的 空白 。 一 方面 ，RMI 使 用 Java 标 准 的 对 象 序列 化 ， 但 
很 难 穿 越 防 火 墙 ; 另 一 方面 ，Hessian/Burlap 能 很 好 地 穿 过 防火 墙 工 
作 ， 但 使 用 目 己 私有 的 一 套 对 象 序 列 化 机 制 。 

就 这 样 ，Spring 的 HttpInvoker 应 运 而 生 。HttpInvoker 是 一 个 新 的 远 
程 调 用 模型 ， 作 为 Spring 框 架 的 一 部 分 ， 来 执行 基于 HTTP 的 远程 调用 


(让 防火 墙 高 兴 的 事 ) ， 并 使 用 Java 的 序列 化 机 制 (这 是 让 程序 
兴 的 事 ) 。 

我 们 首先 看 看 HttpInvoker 的 使 用 示例 。HttpInvoker 是 基于 HTTP 的 
远程 调用 ， 同 时 也 是 使 用 Spring 中 提供 的 web 服 务 作为 基础 ， 所 以 我 们 
的 测试 需要 首先 搭建 Web 工 程 。 


(1) 创建 对 外 接口 。 


public interface HttpInvokerTestl ( 


pall 
ap 


public String getTestPo(String desp); 
j 
(2) 创建 接口 实现 类 。 
public class HttpInvokertestImpl implements HttpInvokerTestl 1 
@Override 
public String getTestPo(String desp) { 


return "getTestPo " + desp; 


} 
(3) 创建 服务 端 配置 文件 applicationContext-server.xmle 

<?xml version="1.0" encoding="UTF-8"?> 

«beans xmlns-"http://www.Springframework.org/schema/beans" 
xmins:xsi-"http://www.w3.0rg/2001/XMLSchema-instance" 
xsi:schemaLocation=" 

http://www. Springframework.org/schema/beans 

http://www. Springframework.org/schema/beans/Spring-beans-3.0.xsd 

"> 


<bean name="httpinvokertest" class="test.HttpInvokertestImpl" /> 


</beans> 
(4) 在 WEB-INF 下 创建 remote-servlet.xml。 

<?xml version="1.0" encoding="UTF-8"?> 

«beans xmlns-"http://www.Springframework.org/schema/beans" 
xmins:xsi-"http://www.w3.0rg/2001/XMLSchema-instance" 
xsi:schemaLocation=" 

http://www. Springframework.org/schema/beans 

http://www. Springframework.org/schema/beans/Spring-beans-3.0.xsd 

"> 


<bean name-"/hit" 


class-"org.Springframework.remoting.httpinvoker.HttpInvokerServiceExpo 
rter"^ 
«property name="service" ref-"httpinvokertest" /> 
<property name-"serviceInterface" 
value-"test.HttpInvokerTestI" /> 
</bean> 
</beans> 
至 此 ， 服 务 端 的 httpInvoker 服务 已 经 搭建 完了 ， 启 动 Web 工程 后 
就 可 以 使 用 我 们 搭建 的 HttpInvoker 服 务 了 。 以 上 代码 实现 了 将 远程 传 
入 的 字符 捉 参 数 处 理 加 入 “getTestPo” 前 级 的 功能 。 服 务 端 搭建 完 基于 
Web 服 务 的 HttpInvoker 后 ， 客 户 端 还 需要 使 用 一 定 的 配置 才能 进行 远 
程 调用 。 
(5) 创建 测试 端 配置 client,xml。 
<?xml version="1.0" encoding="UTF-8"?> 
«beans xmlns-"http://www.Springframework.org/schema/beans" 


xmins:xsi-"http://www.w3.0rg/2001/XMLSchema-instance" 


xsi:schemaLocation=" 
http://www. Springframework.org/schema/beans 
http://www. Springframework.org/schema/beans/Spring-beans-3.0.xsd 
m 


«bean id="remoteService" 


class-"org.Springframework.remoting.httpinvoker.HttpInvokerProxyFactor 
yBean"> 
<property name-"serviceUrl" 
value="http://localhost:8080/httpinvokertest/ 
remoting/hit" /> 
<property name-"serviceInterface" 
value-"test.HttpInvokerTestI" /> 
</bean> 
</beans> 
(6) 创建 测试 类 。 
public class Test { 
public static void main(String[] args) 1 
ApplicationContext context = new 
ClassPathXmlA pplicationContext ("classpath: 
client.xml"); 
HttpInvokerTestI httpInvokerTestI = (HttpInvokerTestI) 
context.getBean 
("remoteService"); 


System.out.printIn(httpInvokerTestI.getTestPo("dddd")); 


运行 测试 类 ， 你 会 看 到 打印 结果 : 

getTestPo dddd 

dddd 是 我 们 传 入 的 参数 ， 而 getTestPo 则 是 在 服务 端 添加 的 字符 
串 。 当 然 ， 上 面 的 服务 搭建 与 测试 过 程 中 都 是 在 一 台 机 器 上 进行 的 ， 
如 果 需 要 在 不 同 机 器 上 进行 测试 ， 还 需要 读者 对 服务 端的 相关 接口 打 
成 JAR 包 并 加 入 到 客户 端的 服务 器 上 。 

12.2.2 现 

对 于 Spring 中 HttpInvoker 服 务 的 实现 ， 我 们 还 是 首先 从 服务 端 进 
行 分 析 。 

根据 remote-servlet.xml 中 的 配置 ， 我 们 分 析 入 口 类 应 该 为 


org.Springframework.remoting.httpinvoker. HttpInvokerServiceExporter, 


那么 同样 ， 根 据 这 个 类 分 析 其 入 口水 数 ， 如 图 12-3 所 示 。 
tEn E ~ 
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12-3 HttpInvokerServiceExporter 类 的 层次 结构 


通过 层次 关系 我 们 看 到 HttpInvokerService Exporter 类 实现 了 
InitializingBean 接口 以 及 Http RequestHandler 接 口 。 分 析 RMI 服 务 时 我 
们 已 经 了 解 到 了 ， 当 某 个 bean 继 承 自 InitializingBean 接 口 的 时 候 ， 


Spring 会 确保 这 个 bean 在 初始 化 时 调用 其 afterPropertiesSet 方法 ， 而 
对 于 HttpRequestHandler 接 口 ， 因 为 我 们 在 配置 中 已 经 将 此 接口 配置 成 
Web 服 务 ， 那 么 当 有 相应 请 求 的 时 候 ，Spring 的 Web 服 务 就 会 将 程序 引 
导 至 HttpRequestHandler 的 handleRequest 方 法 中 。 首 先 ， 我 们 从 
afterPropertiesSet 方 法 开始 分 析 ， 看 看 在 bean 的 初始 化 过 程 中 做 了 哪些 
逻辑 。 
1. 创建 代理 
public void afterPropertiesSet() { 
prepare(); 
} 
public void prepare() { 
this.proxy = getProxyForService(); 
j 
protected Object getProxyForService() 1 
/验证 service 
checkService(); 
/验证 serviceInterface 
checkServiceInterface(); 
/使 用 JDK 的 方式 创建 代理 
ProxyFactory proxyFactory = new ProxyFactory(); 
/添加 代理 接口 
proxyFactory.addInterface(getServiceInterface()); 
if (this.registerTraceInterceptor != null ? 
this.registerTraceInterceptor.booleanValue() : this.interceptors == 
null) { 
/加 入 代理 的 横 切 面 RemoteInvocationTraceInterceptor 并 记录 
Exporter 名 称 


proxyFactory.addAdvice(new RemoteInvocationTraceInterceptor 
(getExporterName())); 
} 
if (this.interceptors != null) { 
AdvisorAdapterRegistry adapterRegistry = 
GlobalAdvisorAdapterRegistry. 
getInstance(); 


for (int i = 0; i < this.interceptors.length; i++) { 


proxyFactory.addA dvisor(adapterRegistry.wrap(this.interceptors][i |)); 
j 
j 
/设置 要 代理 的 目标 类 
proxyFactory.set Target(getService()); 
proxyFactory.setOpaque(true); 
/创建 代理 
return proxyFactory.getProxy(getBeanClassLoader()); 
} 
通过 将 上 面 3 个 方法 串联 ， 可 以 看 到 ， 初 始 化 过 程 中 实现 的 逻辑 主 
要 是 创建 了 一 个 代理 ， 代 理 中 封装 了 对 于 特定 请 求 的 处 理 方 法 以 及 接 
口 等 信息 ， 而 这 个 代理 的 最 关键 目的 是 加 入 了 
RemoteInvocationTraceInterceptor 增 强 器 ， 当 然 创 建 代 理 还 有 些 其 他 好 
处 ， 比 如 代码 优雅 、 方 便 扩展 等 。RemoteInvocationTraceInterceptor 中 
的 增强 主要 是 对 增强 的 目标 方法 进行 一 些 相关 信息 的 日 志 打 印 ， 并 没 
有 在 e 能 性 的 增强 。 那 么 这 个 代理 究竟 是 在 什么 时 
候 使 用 的 呢 ? 暂时 留 下 悬念 ， 我 们 接 下 来 分 析 当 有 Web 请 求 时 
HttpRequestHandler 的 Vae 法 的 处 理 。 


2. 处 理 来 自 客户 端的 request 
当 有 Web 请 求 时 ， 根 据 配置 中 的 规则 会 把 路 径 匹 配 的 访问 直接 引 
入 对 应 的 HttpRequest Handler 中 。 本 例 中 的 Web 请 求 与 普通 的 Web 
请 求 是 有 些 区 别 的 ， 因 为 此 处 的 请 求 包 含 着 HttpInvoker 的 处 理 过 程 。 
public void handleRequest(HttpServletRequest request, 
HttpServletResponse response) 
throws ServletException, IOException 1 
try { 
// 从 request 中 读 取 序列 化 对 象 
RemoteInvocation invocation = readRemoteInvocation(request); 
// 执 行 调用 
RemoteInvocationResult result = 
invokeAndCreateResult(invocation, getProxy()); 
/将 结果 的 序列 化 对 象 写 入 输出 流 
writeRemoteInvocationResult(request, response, result); 
j 
catch (ClassNotFoundException ex) 1 
throw new NestedServletException("Class not found during 
deserialization", ex); 
j 
j 
fthandlerRequestPKZXFR ,. Fel Ris 482008 I| T HttpInvoker A 2B 
大 致 框架 ，HttpInvoker 服 务 简单 点 说 就 是 将 请 求 的 方法 ， 也 就 是 
RemoteInvocation 对 象 ， 从 客户 端 序列 化 并 通过 Web 请 求 出 入 服务 端 ， 
服务 端 在 对 传 过 来 的 序列 化 对 象 进 行 反 序列 化 还 原 RemoteInvocation 实 
例 ， 然 后 通过 实例 中 的 相关 信息 进行 相关 方法 的 调用 ， 并 将 执行 结果 


再 次 的 返回 给 客户 端 。 从 handleRequest 国 数 中 我 们 也 可 以 清晰 地 看 到 
程序 执行 的 框架 结构 。 
(1) 从 request 中 读 取 序列 化 对 象 。 
主要 是 从 HttpServletRequest 提取 相关 的 信息 ， 也 就 是 提取 
HttpServletRequest 中 的 RemoteInvocation 对 象 的 序列 化 信息 以 及 反 序 列 
化 的 过 程 。 
protected RemoteInvocation 
readRemoteInvocation(HttpServletRequest request) 
throws IOException, ClassNotFoundException 1 
return readRemoteInvocation(request, request.getInputStream()); 
j 
protected RemoteInvocation 
readRemoteInvocation(HttpServletRequest request, InputStream is) 
throws IOException, ClassNotFoundException 1 
/创建 对 象 输入 流 
ObjectInputStream ois = 
createObjectInputStream(decorateInputStream(request, is)); 
try { 
/从 输入 流 中 读 取 序 列 化 对 象 
return doReadRemoteInvocation(ois); 
j 
finally { 


ois.close(); 


j 
protected RemoteInvocation 


doReadRemoteInvocation(ObjectInputStream ois) 


throws IOException, ClassNotFoundException { 
Object obj 7 ois.readObject(); 
if (!(obj instanceof RemoteInvocation)) 1 
throw new RemoteException("Deserialized object needs to be 
assignable to type [" + 
RemoteInvocation.class.getName() + "]: " + obj); 
j 
return (RemoteInvocation) obj; 
j 
对 于 序列 化 提取 与 转换 过 程 其 实 并 没有 太 多 需要 解释 的 东西 ， 这 
里 完全 是 按照 标准 的 方式 进行 操作 ， 包 括 创建 ObjectInputStream 以 及 
从 ObjectInputStream 中 提取 对 象 实例 。 
(2) 执行 调用 。 
根据 反 序 列 化 方式 得 到 的 RemoteInvocation 对 象 中 的 信息 ， 进 行 方 
法 调用 。 注 意 ， 此 时 调用 的 实体 并 不 是 服务 接口 或 者 服务 类 ， 而 是 之 
前 在 初始 化 时 候 构造 的 封装 了 服务 接口 以 及 服务 类 的 代理 。 
完成 了 RemoteInvocation 实 例 的 提取 ， 也 就 意味 着 可 以 通过 
RemoteInvocation 实 例 中 提供 的 信息 进行 方法 调用 了 。 
protected RemoteInvocationResult 
invokeAndCreateResult(RemoteInvocation invocation, 
Object targetObject) 1 
try { 
/激活 代理 类 中 对 应 invocation 中 的 方法 
Object value = invoke(invocation, targetObject); 
/封装 结果 以 便于 序列 化 


return new RemoteInvocationResult(value); 


catch (Throwable ex) 1 


return new RemoteInvocationResult(ex); 


这 段 遂 数 有 两 点 需要 说 明 的 地 方 。 
对 应 方法 的 激活 也 就 是 invoke 方 法 的 调用 ， 虽 然 经 过 层 层 环 绕 ， 
但 是 最 终 还 是 实现 了 一 个 我 们 熟知 的 调用 
invocation.invoke(targetObject)， 也 就 是 执行 RemoteInvocation 类 中 的 
invoke 方法 ， 大 致 的 逻辑 还 是 通过 RemoteInvocation 中 对 应 的 方法 信 
息 在 targetObject 上 去 执行 ， 此 方法 在 分 析 RMI 功能 的 时 候 已 经 分 析 
过 ， 不 册 费 述 。 但 是 在 对 于 当前 方法 的 targetObject 参 数 ， 此 
a ， 调 用 代理 类 的 时 候 需 要 考虑 增强 方法 的 调用 ， 
这 是 读者 需 注意 的 地 广 o 
对 于 返回 结果 需要 使 用 RemoteInvocationResult 进行 封装 ， 之 所 以 
需要 通过 使 用 RemoteInvocationResult 类 进行 封闭 ， 是 因为 无 法 保证 对 
于 所 有 操作 的 返回 结果 都 继承 Serializable 接 口 ， 也 就 是 说 无 法 保证 所 
有 返回 结果 都 可 以 直接 进行 序列 化 ， 那 么 ， 就 必须 使 用 
RemoteInvocationResult 类 进行 统一 封装 
(3) 将 结果 的 序列 化 对 象 写 入 输 出 流 。 
同样 这 里 也 包括 结果 的 序列 化 过 程 。 
protected void writeRemoteInvocationResult( 
HttpServletRequest request, HttpServletResponse response, 
RemoteInvocation 
Result result) throws IOException 1 
response.setContentType(getContentType()); 
writeRemoteInvocationResult(request, response, result, 


response.getOutputStream()); 


j 
protected void writeRemoteInvocationResult( 
HttpServletRequest request, HttpServletResponse response, 
RemoteInvocation 
Result result, OutputStream os) 
throws IOException 1 
//FRAN GBI Tit 
ObjectOutputStream oos = 
createObjectOutputStream(decorateOutputStream(request, 
response, OS)); 
try { 
// 将 序列 化 对 象 写 入 输入 流 
doWriteRemoteInvocationResult(result, oos); 
j 
finally { 


oos.close(); 


} 

protected void 
doWriteRemoteInvocationResult(RemoteInvocationResult result, 
ObjectOutput 

Stream oos)throws IOException 1 


oos.writeObject(result); 


12.2.3 现 


分 析 了 服务 端的 解析 以 及 处 理 过 程 后 ， 我 们 接 下 来 分 析 客 户 端 的 
调用 过 程 ， 在 服务 端 调 用 的 分 析 中 我 们 反复 提 到 需要 从 
HttpServletRequest 中 提取 从 客户 端 传 来 的 RemoteInvocation 实例 ， 然 
后 进行 相应 解析 。 所 以 ， 在 客户 端 ， 一 个 比较 重要 的 任务 就 是 构建 
RemoteInvocation 实 例 ， 并 传送 到 服务 端 。 根 据 配置 文件 中 的 信息 ， 我 
们 还 是 首先 锁定 HttpInvokerProxyFactoryBean 类 ， 并 查看 其 层次 结构 ， 
如 图 12-4 所 示 。 

从 层次 结构 中 我 们 看 到 ，HttpInvokerProxyFactoryBean 类 同样 实现 
了 InitializingBean 接 口 。 同 时 ， 又 实现 了 FactoryBean 以 及 
MethodInterceptor。 这 已 经 是 老生 常 谈 的 问题 了 ， 实 现 这 几 个 接口 以 及 
这 几 个 接口 在 Spring 中 会 有 什么 作用 就 不 再 次 述 了 ， 我 们 还 是 根据 实 
现 的 InitializingBean 接 口 分 析 初 始 化 过 程 中 的 逻辑 。 
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12-4 HttpInvokerProxyFactoryBean 类 的 层次 结构 


public void afterPropertiesSet() { 
super.afterPropertiesSet(); 
if (getServiceInterface() == null) { 
throw new Illegal ArgumentException(" Property 
'serviceInterface' is 
required"); 
i 
/创建 代理 并 使 用 当前 方法 为 拦截 器 增强 
this.serviceProxy = new ProxyFactory(getServiceInterface()， 
this).getProxy 
(getBeanClassLoader()); 

} 

在 afterPropertiesSet 中 主要 创建 了 一 个 代理 ， 该 代理 封装 了 配置 的 
服务 接口 ， 并 使 用 当前 类 也 就 是 HttpInvokerProxyFactoryBean 作为 增 
强 。 因 为 HttpInvokerProxyFactoryBean 实现 了 MethodInterceptor 方 法 ， 
所 以 可 以 作为 增强 拦截 器 。 

同样 ， 又 由 于 HttpInvokerProxyFactoryBean 实 现 了 FactoryBean 接 
口 ， 所 以 通过 Spring 中 普通 方式 调用 该 beaan 时 调用 的 并 不 是 该 bean 本 
身 ， 而 是 此 类 中 getObject 方 法 返回 的 实例 ， 也 就 是 实例 化 过 程 中 所 创 
建 的 代理 。 

public Object getObject() 1 

return this.serviceProxy; 

j 

那么 ， 综 合 之 前 的 使 用 示例 ， 我 们 再 次 回顾 一 下 ， 
HttpInvokerProxyFactoryBean 类 型 bean 在 初始 化 过 程 中 创建 了 封装 服务 
接口 的 代理 ， 并 使 用 自身 作为 增强 拦截 器 ， 然 后 又 因为 实现 了 
FactoryBean 接 口 ， 所 以 获取 Bean 的 时 候 返 回 的 其 实 是 创建 的 代理 。 那 


么 ， 汇 总 上 面 的 逻辑 ， 当 调用 如 下 代码 时 ， 其 实 是 调用 代理 类 中 的 服 
务 方法 ， 而 在 调用 代理 类 中 的 服务 方法 时 又 会 使 用 代理 类 中 加 入 的 增 
强 器 进行 增强 。 
ApplicationContext context = new 
ClassPathXmlA pplicationContext(" classpath:client.xml"); 
HttpInvokerTestI httpInvokerTestI = (HttpInvokerTestI) 
context.getBean(" remoteService"); 
System.out.printIn(httpInvokerTestI.getTestPo("dddd")); 
这 时 ， 所 有 的 逻辑 分 析 其 实 已 经 被 转向 了 对 于 增强 器 也 就 是 
HttpInvokerProxyFactoryBean 类 本 身 的 invoke 方 法 的 分 析 。 
在 分 析 invoke 方 法 之 前 ， 其 实 我 们 已 经 猜 出 了 该 方法 所 提供 的 主 
要 功能 就 是 将 调用 信息 封装 在 RemoteInvocation 中 ， 发 送 给 服务 端 并 等 
待 返回 结果 。 
public Object invoke(MethodInvocation methodInvocation) throws 
Throwable { 
if (AopUtils.isToStringMethod(methodInvocation.getMethod())) 1 
return "HTTP invoker proxy for service URL [" * 
getServiceUrl() + "|"; 
j 
/将 要 调用 的 方法 封装 为 RemoteInvocation 
RemoteInvocation invocation = 
createRemoteInvocation(methodInvocation); 
RemoteInvocationResult result = null; 
try { 
/远程 执行 方法 


result = executeRequest(invocation, methodInvocation); 


catch (Throwable ex) 1 
throw convertHttpInvokerAccessException(ex); 
j 
try { 
// 提 取 结 果 
return recreateRemoteInvocationResult(result); 
j 
catch (Throwable ex) 1 
if (result.hasInvocationTargetException()) 1 
throw ex; 
j 
else { 
throw new RemoteInvocationFailureException( "Invocation of 
method [" + 
methodInvocation.getMethod() + 
"| failed in HTTP invoker remote service at [" + 
getServiceUrl() 


十 Iss ex); 


} 
函数 主要 有 3 个 步骤 。 
(1) 构建 RemoteInvocation 实 例 。 
为 是 代理 中 增强 方法 的 调用 ， 调 用 的 方法 及 参数 信息 会 在 代理 
中 封装 至 MethodInvocation 实 例 中 ， 并 在 增强 方 器 中 进行 传递 ， 也 就 
意味 着 当 程序 进入 invoke 方 法 时 其 实 是 已 经 包含 了 调用 的 接口 的 相关 


信息 的 ， 那 么 ， 首 先 要 做 的 就 是 将 MethodInvocation 中 的 信息 提取 并 
构建 RemoteInvocation 实 例 。 
(2) 远程 执行 方法 。 
(3) 提取 结果 。 
考虑 到 序列 化 的 问题 ， 在 Spring 中 约定 使 用 HttpInvoker 方 式 进行 
远程 方法 调用 时 ， 结 果 使 用 RemoteInvocationResult 进行 封装 ， 那 么 在 
提取 结果 后 还 需要 从 封装 的 结果 中 提取 对 应 的 结果 。 
而 在 这 三 个 步骤 中 最 为 关键 的 就 是 远程 方法 的 执行 。 执 行 远 程 调 
用 的 首要 步骤 就 是 将 调用 方法 的 实例 写 入 输出 流 中 。 
protected RemoteInvocationResult executeRequest( 
RemoteInvocation invocation, MethodInvocation originalInvocation) 
throws Exception 1 
return executeRequest(invocation); 
} 
protected RemoteInvocationResult executeRequest(RemoteInvocation 
invocation) throws Exception 1 
return getHttpInvokerRequestExecutor().executeRequest(this, 
invocation); 
j 
public final RemoteInvocationResult executeRequest( 
HttpInvokerClientConfiguration config, RemoteInvocation invocation) 
throws 
Exception 1 
// 获 取 输 出 流 
ByteArrayOutputStream baos = 
getByteArrayOutputStream(invocation); 
if (logger.isDebugEnabled()) { 


logger.debug(" Sending HTTP invoker request for service at [" + 


config.getServiceUrl() + 
"], with size " + baos.size()); 


j 
return doExecuteRequest(config, baos); 
j 
在 doExecuteRequest 方 法 中 真正 实现 了 对 远程 方法 的 构造 与 通信 ， 
与 远程 方法 的 连接 功能 实现 中 ，Spring 引 入 了 第 三 方 JAR : 
HttpClient。 HttpClient 是 Apache Jakarta Common 下 的 子 项 目 ， 可 以 用 
来 提供 高 效 的 、 最 新 的 、 功 能 丰富 的 支持 HTTP 协议 的 客户 端 编程 工具 
包 ， 并 且 它 支持 HTTP 协 议 最 新 的 版 本 和 建议 。 对 HttpClient 的 具体 使 
用 方法 有 兴趣 的 读者 可 以 参考 更 多 的 资料 和 文档 。 
protected RemoteInvocationResult doExecuteRequest( 
HttpInvokerClientConfiguration config, ByteArrayOutputStream baos) 
throws IOException, ClassNotFoundException 1 
/创建 HttpPost 
HttpPost postMethod = createHttpPost(config); 
/设置 含有 方法 的 输出 流 到 post 中 
setRequestBody(config, postMethod, baos); 
try { 
/执行 方法 并 等 待 结果 响应 
HttpResponse response = executeHttpPost(config, 
getHttpClient(), postMethod); 
/验证 


validateResponse(config, response); 


/提取 返回 的 输入 流 
InputStream responseBody = getResponseBody(config, 
response); 
/从 输入 流 中 提取 结果 
return readRemoteInvocationResult(responseBody, 
config.getCodebaseUrl()); 
j 
finally { 
if (releaseConnectionMethod != null)1 
ReflectionUtils.invokeMethod(releaseConnectionMethod, 
postMethod); 
j 


j 
接 下 来 我 们 逐步 分 析 客 户 端 实现 的 逻辑 。 
1. 创建 HttpPost 
由 于 对 于 服务 端 方法 的 调用 是 通过 Post 方 式 进行 的 ， 那 么 首先 要 
做 的 就 是 构建 HttpPost， 构 建 HttpPost 过 程 中 可 以 设置 一 些 必 要 的 参 
数 。 
protected PostMethod 
createPostMethod(HttpInvokerClientConfiguration config) throws 
IOException 1 
/设置 需要 访问 的 ul 
PostMethod postMethod = new 
PostMethod(config.getServiceUrl()); 
LocaleContext locale = LocaleContextHolder.getLocaleContext(); 
if (locale != null) 1 


/加 入 AcceptrLanguage 属 性 


postMethod.addRequestHeader(HTTP_HEADER ACCEPT LANGUAGE 
, StringUtils. 
toLanguageTag(locale.getLocale())); 
j 
if (isAcceptGzipEncoding()) { 
/加 入 AcceptrEncoding 属 性 


postMethod.addRequestHeader(HTTP HEADER ACCEPT ENCODING， 
ENCODING_GZIP); 
} 
return postMethod; 
2. 设置 RequestBody 
构建 好 PostMethod 实 例 后 便 可 以 将 存储 RemoteInvocation 实 例 的 序 
列 化 对 象 的 输出 流 设置 进去 ， 当 然 这 里 需要 注意 的 是 传 入 的 
ContentType 类 型 ， 一 定 要 传 入 application/x-java-serialized-object 以 保证 
服务 端 解析 时 会 按照 序列 化 对 象 的 解析 方式 进行 解析 。 
protected void SetRequestBody( 
HttpInvokerClientConfiguration config, PostMethod postMethod, 
ByteArrayOutputStream 
baos) 
throws IOException { 
/将 序列 化 流 加 入 到 postMethod 中 并 声明 ContentType 类 型 为 


application/x-java-serialized-object 


postMethod.setRequestEntity(new 
ByteArrayRequestEntity(baos.toByteArray(), 
getContentType())); 
} 
3. 执行 远程 方法 
通过 HttpClient 所 提供 的 方法 来 直接 执行 远程 方法 。 
protected void executePostMethod( 
HttpInvokerClientConfiguration config, HttpClient httpClient, 
PostMethod 
postMethod) throws IOException 1 
httpClient.executeMethod(postMethod); 
j 
4. 远程 相应 验证 
对 于 HTTP 调 用 的 响应 码 处 理 ， 大 于 300 则 是 非 正 常 调用 的 响应 
B3, 
protected void validateResponse(HttpInvokerClientConfiguration 
config, PostMethod 
postMethod) 
throws IOException 1 
if (postMethod.getStatusCode() >= 300) { 


throw new HttpException( 
"Did not receive successful HTTP response: status code = "+ 


postMethod.getStatusCode() + 
", Status message = [" + postMethod.getStatusText() + "]"); 


j 
5。 提 取 响 应 信息 
从 服务 器 返回 的 输入 流 可 能 是 经 过 压缩 的 ， 不 同 的 方式 采用 不 同 
的 办 法 进行 提前 。 
protected InputStream 
getResponseBody(HttpInvokerClientConfiguration config, PostMethod 
postMethod) 
throws IOException 1 
if (isGzipResponse(postMethod)) { 
return new 
GZIPInputStream(postMethod.getResponseBodyAsStream()); 
j 
else { 
return postMethod.getResponseBodyAsStream(); 


j 
c. 提取 返回 结果 
提取 结果 的 流程 主要 是 从 输入 流 中 提取 响应 的 序列 化 信息 。 
protected RemoteInvocationResult 
readRemoteInvocationResult(InputStream is, String 
codebaseUrl) 
throws IOException, ClassNotFoundException 1 
ObjectInputStream ois = 
createObjectInputStream(decorateInputStream(is), 
codebaseUrl); 
try 1 
return doReadRemoteInvocationResult(ois); 


j 
finally 1 
ois.close(); 


} 


第 13 章 “Spring 消息 


Java 消 息 服 务 (Java Message Service, JMS) 应 用 程序 接口 是 一 个 
Java 平 台中 关于 面向 消息 中 间 件 (MOM) 的 API， 用 于 在 两 个 应 is 
序 之 间或 分 布 式 系统 中 发 送 消 息 ， 进 行 异步 通信 。Java 消 息 服务 
个 与 具体 平台 无 天 的 APT， 绝 大 多 数 MOM 提 供 商都 对 MS 提供 支持 

Java 消 息 服务 的 规范 包括 两 种 消息 模式 ， 点 对 点 和 发 布 者 /订阅 
者 。 许 多 提供 丙 支 持 这 一 通用 框架 。 因 此 ， 程 序 员 可 以 在 他 们 的 分 布 
式 软 件 中 实现 面向 消息 的 操作 ， 这 些 操 作 将 具有 不 同 面向 消息 中 间 件 
产品 的 可 移植 性 。 

Java 消 息 服务 支持 同步 和 异步 的 消息 处 理 ， 在 某 些 场 景 下 ， 异 步 
消息 是 必要 的 ， 而 且 比 同步 消息 操作 更 加 便利 。 

Java 消 息 服务 支持 面向 事件 的 方法 接收 消息 ， 事 件 驱 动 的 程序 设 
计 现 在 被 广泛 认为 是 一 种 富有 成 效 的 程序 设计 范例 ， 程 序 员 们 都 相当 
PK, 

在 应 用 系统 开发 时 ，Java 消 息 服 务 可 以 推迟 选择 面 对 消 息 中 间 件 
产品 ， 也 可 以 在 不 同 的 面 对 消 息 中 间 件 切换 。 

本 章 以 Java 消 息 服 务 的 开源 实现 产品 ActiveMQ 为 例 来 进行 Spring 
整合 消息 服务 功能 的 实现 分 析 。 


13.1 JMS 的 独立 使 用 


尽管 大 多 数 的 Java 消 息 服务 的 使 用 都 会 跟 Spring 相 结合 ， 但 是 ， 我 
们 还 是 非常 有 必要 了 人 解 消息 的 独立 使 用 方法 ， 这 对 于 我 们 了 解 消息 的 
实现 原理 以 及 后 续 的 与 Spring 整合 实现 分 析 都 非常 重要 。 当 然 在 消息 
服务 的 使 用 前 ， 需 要 我 们 先 开启 消息 服务 器 ， 如 果 是 Windows 系 统 下 
可 以 直接 双击 ActiveMQ 安 装 目 录 下 的 bin 目 录 下 的 activemq.bat 文 件 来 
启动 消息 服务 器 。 
消息 服务 的 使 用 除了 要 开启 消息 服务 器 外 ， 还 需要 构建 消息 的 发 
送 端 与 接收 端 ， 发 送 端 主要 用 来 将 包含 业务 逻辑 的 消息 发 送 至 消息 服 
务 器 ， 而 消息 接收 端 则 用 于 将 服务 器 中 的 消息 提取 并 进行 相应 的 处 
理 。 
(1) 发 送 端 实现 
发 送 端 主要 用 于 发 送 消息 到 消息 服务 器 ， 以 下 为 发 送 消息 测试 ， 
尝试 发 送 三 条 消息 到 消息 服务 器 ， 消 息 的 内 容 为 “大 家 好 这 是 个 测 
public class Sender { 
public static void main(String[] args) throws Exception 1 
ConnectionFactory connectionFactory = new 
ActiveMQConnectionFactory(); 
Connection connection = connectionFactory.createConnection(); 
//connection.start(); 
Session session = connection.createSession(Boolean. TRUE, 
Session. AUTO_ACKNOWLEDGE); 
Destination destination = session.createQueue("my-queue"); 
MessageProducer producer = 
session.createProducer(destination); 


for (int i = 0; i < 3; i++) { 


TextMessage message = session.createTextMessage(" 大 家 好 
这 是 个 测试 "); 

Thread.sleep(1000); 
/通过 消息 生产 者 发 出 消息 
producer.send(message); 
} 

session.commit(); 
session.close(); 


connection.close(); 


} 
上 面 的 函数 实现 很 容易 让 我 们 联想 到 数据 库 的 实现 ， 在 函数 开始 
时 需要 一 系列 元 余 的 但 又 必 不 可 少 的 用 于 连接 的 代码 ， 而 其 中 真正 用 
于 发 送 消息 的 代码 其 实 很 简单 。 
(2) 接收 端 实现 。 
接收 端 主要 用 于 连接 消息 服务 器 并 接收 服务 器 上 的 消息 。 
public class Receiver { 
public static void main(String[] args) throws Exception 1 
ConnectionFactory connectionFactory = new 
ActiveMQConnectionFactory(); 
Connection connection = connectionFactory.createConnection(); 
connection.start(); 
final Session session - connection.createSession(Boolean. TRUE, 
Session. AUTO _ 
ACKNOWLEDGE); 


Destination destination = session.createQueue("my-queue"); 


MessageConsumer consumer = 
session.createConsumer(destination); 
int i=0; 
while(i<3) 1 
i++; 
TextMessage message = (TextMessage) consumer.receive(); 
session.commit(); 
/TODO something.... 
System.out.println(" 收 到 消息 : " + message.getText()); 
j 
session.close(); 


connection.close(); 


) 
程序 测试 的 顺序 是 首先 开启 发 送 端 ， 然 后 向 服务 器 发 送 消 息 ， 接 
着 再 开启 接收 端 ， 不 出 意外 ， 就 会 接收 到 发 送 端 发 出 的 消息 。 


13.2 Spring 整 合 ActiveMQ 


整个 消息 的 发 送 与 接收 过 程 非常 简单 ， 但 是 其 中 却 参 杂 着 大 量 的 
风 余 代码 ， 比 如 Connection 的 创建 与 关闭 ，Session 的 创建 与 关闭 等 ， 
为 了 消除 这 一 匈 余 工作 量 ，Spring 进 行 了 进一步 的 封装 。Spring 下 的 
ActiveMQ 使 用 方式 如 下 。 

(1) Spring 配 置 文 件 。 

配置 文件 是 Spring 的 核心 ，Spring 整合 消息 服务 的 使 用 也 从 配置 
文件 配置 开始 。 类 似 于 数据 库 操作 ，Spring 也 将 ActiveMQ 中 的 操作 统 
一 封装 至 JmsTemplate 中 ， 以 方便 我 们 统一 使 用 。 所 以 ， 在 Spring 的 核 


心 配置 文件 中 首先 要 注册 JmsTemplate 类 型 的 bean。 当 然 ， 
ActiveMQConnection Factory 用 于 连接 消息 服务 器 ， 是 消息 服务 的 基 
础 ， 也 要 注册 。ActiveMQQueue 则 用 于 指定 消息 的 目的 地 。 
«beans? 
<bean id="connectionFactory" 
class="org.apache.activemq.ActiveMQConnectionFactory"> 
<property name="brokerURL"> 
<value>tcp://localhost:61616</value> 
</property> 
</bean> 
<bean id="jmsTemplate" 
class="org.Springframework.jms.core.JmsTemplate"> 
<property name="connectionFactory"> 
<ref bean="connectionFactory" /> 
</property> 
</bean> 
<bean id="destination" 
class="org.apache.activemgq.command.ActiveMQQueue"> 
<constructor-arg index="0"> 
<value>HelloWorldQueue</value> 
</constructor-arg> 
</bean> 
</beans> 
(2) 发 送 端 。 
有 了 以 上 的 配置 ，Spring 就 可 以 根据 配置 信息 简化 我 们 的 工作 
量 。Spring 中 使 用 发 送 消 息 到 消息 服务 器 ， 省 去 了 宛 余 的 Connection 以 
及 Session 等 的 创建 与 销毁 过 程 ， 简 化 了 工作 量 。 


public class HelloWorldSender { 
public static void main(String args[]) throws Exception 1 

ApplicationContext context = new 
ClassPathXmlApplicationContext( 

new String[] { "test/activeMQ/Spring/applicationContext.xml" 
y 

JmsTemplate jmsTemplate = (JmsTemplate) 
context.getBean("jmsTemplate"); 

Destination destination = (Destination) 
context.getBean("destination"); 

jmsTemplate.send(destination, new MessageCreator() { 

public Message createMessage(Session session) throws 
JMSException { 
return Session.createTextMessage(" 大 家 好 这 个 是 测试 ! "); 


D; 


(3) 接收 端 。 
同样 ， 在 Spring 中 接收 消息 也 非常 方便 ，Spring 中 连接 服务 器 接收 
消息 的 示例 如 下 : 
public class HelloWorldReciver 1 
public static void main(String args[]) throws Exception 1 
ApplicationContext context = new 
ClassPathXmlApplicationContext( 
new String[] { "test/activeMQ/Spring/applicationContext.xml" 


D; 


JmsTemplate jmsTemplate = (JmsTemplate) 
context.getBean("jmsTemplate"); 

Destination destination = (Destination) 
context.getBean("destination"); 

TextMessage msg = (TextMessage) 
jmsTemplate.receive(destination); 


System.out.printIn("reviced msg is:" + msg.getText()); 


} 

到 这 里 我 们 已 经 完成 了 Spring 消息 的 发 送 与 接收 操作 。 但 是 ， 如 
HelloWorldReciver 中 所 示 的 代码 ， 使 用 jmsTemplate.receive(destination) 
方法 只 能 接收 一 次 消息 ， 如 果 未 接收 到 消息 ， 则 会 一 直 等 待 ， 当 然 用 
户 可 以 通过 设置 timeout 属性 来 控制 等 待 时 间 ， 但 是 一 旦 接收 到 消息 
本 次 接收 任务 就 会 结束 ， 虽 然 用 户 可 以 通过 while(true) 的 方式 来 实现 
循环 监听 消息 服务 器 上 的 消息 ， 还 有 一 种 更 好 的 解决 办 法 : 创建 消息 
监听 器 。 消 息 监听 器 的 使 用 方式 如 下 。 

(1) 创建 消息 监听 器 。 

用 于 监听 消息 ， 一 旦 有 新 消息 Spring 会 将 消息 引导 至 消息 监听 器 
以 方便 用 户 进行 相应 的 逻辑 处 理 。 

public class MyMessageListener implements MessageListener{ 

@Override 
public void onMessage(Message arg0) { 
TextMessage msg = (TextMessage) arg0; 
try { 
System.out.printIn(msg.getText()); 
} catch (JMSException e) { 
e.printStackTrace(); 


j 
(2) 修改 配置 文件 。 
为 了 使 用 消息 监听 器 ， 需 要 在 配置 文件 中 注册 消息 容器 ， 并 将 消 
息 监听 器 注入 到 容器 中 。 
<beans> 
<bean id="connectionFactory" 
class="org.apache.activemq.ActiveMQConnectionFactory"> 
<property name="brokerURL"> 
<value>tcp://localhost:61616</value> 
</property> 
</bean> 
<bean id="jmsTemplate" 
class="org.Springframework.jms.core.JmsTemplate"> 
<property name="connectionFactory"> 
<ref bean="connectionFactory" /> 
</property> 
</bean> 
<bean id="destination" 
class="org.apache.activemgq.command.ActiveMQQueue"> 
<constructor-arg index="0"> 
<value>HelloWorldQueue</value> 
</constructor-arg> 
</bean> 
<bean id="myTextListener" 


class="test.activeMQ.Spring.MyMessageListener" /> 


<bean id="javaConsumer" 


class="org.Springframework.jms. listener. DefaultMessageListenerContainer 
i 
<property name-"connectionFactory" ref="connectionFactory" 
/> 
«property name-"destination" ref="destination" /> 
«property name-"messageL istener" ref-"myTextListener" /> 
</bean> 
</beans> 
通过 以 上 的 修改 便 可 以 进行 消息 监听 的 功能 了 ， 一 旦 有 消息 传 入 
至 消息 服务 器 ， 则 会 被 消息 监听 器 监听 到 ， 并 由 Spring 将 消息 内 容 引 
导 至 消息 监听 器 的 处 理 函 数 中 等 待 用 户 的 进一步 逻辑 处 理 。 


13.3 源码 分 析 


尽管 消息 接收 可 以 使 用 消息 监听 器 的 方式 替代 模版 方法 ， 但 是 在 
发 送 的 时 候 是 无 法 替代 的 ， 在 Spring 中 必须 要 使 用 JmsTemplate 提 供 的 
方法 来 进行 发 送 操作 ， 可 见 JmsTemplate 类 的 重要 性 ， 那 么 我 们 对 于 
Spring 整合 消息 服务 的 分 析 就 从 JmsTemplate 开 始 。 


13.3.1 Jms Template 
在 代码 与 Spring 整合 的 实例 中 ， 我 们 看 到 Spring 采用 了 与 JDBC 等 


一 贯 的 套路 ， 为 我 们 提供 了 JmsTemplate 来 封装 常用 操作 。 查 看 
JmsTemplate 的 类 型 层级 结构 图 ， 如 图 13-1 所 示 。 


«S [Rn 目 ~ 
4 © JmsTemplate 
4 (9^ ImsDestinationAccessor 
4 (9^ ImsAccessor 
© Object 
© InitializingBean 


Q JmsOperations 


图 13-1 JmsTemplate 的 类 型 层级 结构 图 


首先 还 是 按照 一 贯 的 分 析 套 路 ， 提 取 我 们 感 兴趣 的 接口 
InitializingBean， 接 口 方法 实现 是 在 JmsAccessor 类 中 ， 如 下 : 
public void afterPropertiesSet() { 
if (getConnectionFactory() == null) { 
throw new IllegalArgumentException(" Property 
'connectionFactory' is required"); 
j 
j 
发 现 国 数 中 只 是 一 个 验证 的 功能 ， 并 没有 逻辑 实现 。 丢 掉 这 个 线 
索 ， 我 们 转向 实例 代码 的 分 析 。 首 先 以 发 送 为 例 ， 在 Spring 中 发 送 消 
息 可 以 通过 JmsTemplate 中 提供 的 方法 来 实现 。 
public void send(final Destination destination, final MessageCreator 
messageCreator) 
throws JmsException 
使 用 方式 如 下 : 
jmsTemplate.send(destination, new MessageCreator() 1 
public Message createMessage(Session session) throws 
JMSException 1 


return Session.createTextMessage(" 大 家 好 这 个 是 测试 ! "); 
j 
y 
我 们 就 跟着 程序 流 ， 进 入 函数 send 查 看 其 产 代 码 : 
public void send(final Destination destination, final MessageCreator 
messageCreator) 
throws JmsException { 
execute(new SessionCallback<Object>() { 
public Object doInJms(Session session) throws JMSException { 
doSend(session, destination, messageCreator); 
return null; 
j 
}, false); 
} 
现在 的 风格 不 得 不 让 我 们 回想 起 JdbcTemplate 的 类 实现 风格 ， 极 
为 相似 ， 都 是 提取 一 个 公共 的 方法 作为 最 底层 、 最 通用 的 功能 实现 ， 
然后 又 通过 回调 函数 的 不 同 来 区 分 个 性 化 的 功能 。 我 们 首先 查看 通用 
代码 的 抽取 实现 。 
1. 通用 代码 抽取 
根据 之 前 分 析 JdbcTemplate 的 经 验 ， 我 们 推断 ， 在 execute 中 一 定 
是 封装 了 Connection 以 及 Session 的 创建 操作 。 
public «T» T execute(SessionCallback<T> action, boolean 
startConnection) throws JmsException 1 
Assert.notNull(action, "Callback object must not be null"); 
Connection conToClose - null; 
Session session ToClose = null; 


try { 


Session sessionToUse = 
ConnectionFactoryUtils.doGetTransactionalSession( 
getConnectionFactory(), this.transactionalResourceFactory, 
startConnection); 
if (sessionToUse == null) { 
/创建 connection 
conToClose = createConnection(); 
/根据 connection 创 建 session 
sessionToClose = createSession(conToClose); 
/是 否 开启 向 服务 器 推送 连接 信息 ， 只 有 接收 信息 时 需 
要 ， 发 送 时 不 需 
if (startConnection) { 
conToClose.start(); 
} 
sessionToUse = sessionToClose; 
} 
if (logger.isDebugEnabled()) { 
logger.debug(" Executing callback on JMS Session: " + 


session ToUse); 
j 
/调用 回调 函数 


return action.doInJms(sessionToUse); 


} 
catch (JMSException ex) { 


throw convertJmsAccessException(ex); 


} 
finally { 


/天 闭 session 
JmsUtils.closeSession(sessionToClose); 
/释放 连接 
ConnectionFactoryUtils.releaseConnection(conToClose, 
getConnectionFactory(), 
startConnection); 
} 

} 

在 展示 单独 使 用 activeMQ 时 ， 我 们 知道 为 了 发 送 一 条 消息 需要 做 
很 多 工作 ， 需 要 很 多 的 辅助 代码 ， 而 这 些 代 码 又 都 是 千篇一律 的 ， 没 
有 任何 的 差异 ， 所 以 execute 方法 的 目的 就 是 帮助 我 们 抽 离 这 些 见 余 
代码 使 我 们 更 加 专注 于 业务 逻辑 的 实现 。 从 遂 数 中 看 ， 这 些 见 余 代 码 
包括 创建 Connection、 创 建 Session、 当 然 也 包括 关闭 Session 和 关闭 
Connection。 而 在 准备 工作 结束 后 ， 调 用 回调 函数 将 程序 引入 用 户 自 
定义 实现 的 个 性 化 处 理 。 至 于 如 何 创建 Session 与 Connection， 有 兴趣 
的 读者 可 以 进一步 研究 Mybatis 的 源码 。 

2. 发 送 消息 的 实现 

有 了 基 类 辅助 实现 ， 使 Spring 更 加 专注 于 个 性 的 处 理 ， 也 就 是 说 
Spring 使 用 execute 方 法 中 封装 了 元 余 代 码 ， 而 将 个 性 化 的 代码 实现 放 
在 了 回调 函数 doImnJms 孙 数 中 。 在 发 送 消息 的 功能 中 回调 函数 通过 局 部 
类 实现 。 

new SessionCallback<Object>() 1 

public Object doInJms(Session session) throws JMSException 1 
doSend(session, destination, messageCreator); 


return null; 


此 时 的 发 送 逻 辑 已 经 完全 被 转向 了 doSend 方 法 ， 这 样 使 整个 功能 
实现 变 得 更 加 清晰 。 
protected void doSend(Session session, Destination destination， 
MessageCreator 
messageCreator) 
throws JMSException { 
Assert.notNull(messageCreator, "MessageCreator must not be 
null"); 
MessageProducer producer = createProducer(session, destination); 
try { 
Message message = messageCreator.createMessage(session); 
if (logger.isDebugEnabled()) { 
logger.debug( Sending created message: " + message); 
j 
doSend(producer, message); 
// Check commit - avoid commit call within a JTA transaction. 
if (session.getTransacted() && 
isSessionLocallyTransacted(session)) 1 
// Transacted session created by this template -> commit. 


JmsUtils.commitIfNecessary(session); 


} 
finally { 


JmsUtils.closeMessageProducer(producer); 


protected void doSend(MessageProducer producer, Message message) 
throws JMSException { 
if (isExplicitQosEnabled()) { 
producer.send(message, getDeliveryMode(), getPriority(), 
getTimeToLive()); 
} 
else { 


producer.send(message); 


} 

在 演示 独立 使 用 消息 功能 的 时 候 ， 我 们 大 体 了 解 了 消息 发 送 的 基 
本 套路 ， 昌 然 这 些 步 骤 已 经 被 Spring 拆 得 支离破碎 ， 但 是 我 们 还 是 能 
捕捉 到 一 些 影子 。 在 发 送 消息 还 是 遵循 着 消息 发 送 的 规则 ， 比 如 根据 
Destination 创 建 MessageProducer、 创 建 Message， 并 使 用 
MessageProducer 实 例 来 发 送 消息 。 

3. 接收 消息 

我 们 通常 使 用 jmsTemplate.receive(destination) 来 接收 简单 的 消息 ， 
那么 这 个 功能 Spring 是 如 何 封装 的 呢 ? 


public Message receive(Destination destination) throws JmsException 


return receiveSelected(destination, null); 
} 
public Message receiveSelected(final Destination destination, final 
String messageSelector) 
throws JmsException { 


return execute(new SessionCallback<Message>() 1 


public Message doInJms(Session session) throws JMSException 


return doReceive(session, destination, messageSelector); 
j 
}, true); 
} 
protected Message doReceive(Session session, Destination destination, 
String messageSelector) 
throws JMSException { 
return doReceive(session, createConsumer(session, destination, 
messageSelector)); 
} 
protected Message doReceive(Session session, MessageConsumer 
consumer) throws JMSException { 
try { 
// Use transaction timeout (if available). 
long timeout = getReceiveTimeout(); 
JmsResourceHolder resourceHolder = 
(JmsResourceHolder) 
TransactionS ynchronizationManager.getResource 
(getConnectionFactory()); 
if (resourceHolder != null && resourceHolder.hasTimeout()) { 
timeout = Math.min(timeout, 
resourceHolder.getTimeToLiveInMillis()); 
j 
Message message = doReceive(consumer, timeout); 


if (session.getTransacted()) { 


// Commit necessary - but avoid commit call within a JTA 
transaction. 
if (isSessionLocallyTransacted(session)) 1 
// Transacted session created by this template -> commit. 


JmsUtils.commitIfNecessary(session); 


} 

else if (isClientAcknowledge(session)) { 
// Manually acknowledge message, if any. 
if (message != null) { 


message.acknowledge(); 


} 

return message; 
} 
finally { 


JmsUtils.closeMessageConsumer(consumer); 


j 
private Message doReceive(MessageConsumer consumer, long 
timeout) throws JMSException 1 
if (timeout == RECEIVE TIMEOUT NO WAIT) { 
return consumer.receiveNoWait(); 
j 
else if (timeout > 0) ( 


return consumer.receive(timeout); 


else { 


return consumer.receive(); 


} 

实现 的 套路 与 发 送 差不多 ， 同 样 还 是 使 用 execute HARET 
余 的 公共 操作 ， 而 最 终 的 目标 还 是 通过 consumer.receive() 来 接收 消 
息 ， 其 中 的 过 程 就 是 对 于 MessageConsumer 的 创建 以 及 一 些 辅 助 操 
(Fs 


13.3.2 监听 器 容 


消息 监听 器 容器 是 一 个 用 于 查看 JMS 目标 等 待 消息 到 达 的 特殊 
bean, 一旦 消息 到 达 它 就 可 以 获取 到 消息 ， 并 通过 调用 onMessage() 方 
法 将 消息 传递 给 一 个 MessageListener 实 现 。Spring 中 消息 监听 器 容器 的 
类 型 如 下 。 

SimpleMessageListenerContainer: 最 简单 的 消息 监听 器 容器 ， 只 
能 处 理 固定 数量 的 JMS 会 话 ， 且 不 支持 事务 。 

DefaultMessageListenerContainer: 这 个 消息 监听 器 容器 建立 在 
SimpleMessageListener Container 容 器 之 上 ， 添 加 了 对 事务 的 支持 。 

serversession.ServerSessionMessage.ListenerContainer: 这 是 功能 最 
强大 的 消息 监听 器 ， 与 DefaultMessageListenerContainer 相 同 ， 它 支持 
事务 ， 但 是 它 还 允许 动态 地 管理 JMS 会 话 。 

“FILA DefaultMessageListenerContainer 为 例 进 行 分 析 ， 看 看 消息 
监听 器 容器 的 实现 。 在 之 前 消息 监听 器 的 使 用 示例 中 ， 我 们 了 解 到 在 
使 用 消息 监听 器 容器 时 一 定 要 将 自 定义 的 消息 监听 器 置 入 到 容器 中 ， 
这 样 才 可 以 在 收 到 信息 时 ， 容 器 把 消息 转向 监听 器 处 理 。 查 看 
DefaultMessageListenerContainer 层 次 结构 图 ， 如 图 13-2 所 示 。 
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13-2 DefaultMessageListenerContainer 层 次 结构 


同样 ， 我 们 看 到 此 类 实现 了 InitializingBean 接 口 ， 按 照 以 往 的 风格 
我 们 还 是 首先 查看 接口 方法 afterPropertiesSet() 中 的 逻辑 ， 其 方法 实现 
在 其 父 类 AbstracUmsListeningContainer 中 。 
public void afterPropertiesSet() { 
/验证 connectionFactory 
super.afterPropertiesSet(); 
/验证 配置 文件 
validateConfiguration(); 
/初始 化 
initialize(); 
j 
监听 器 容器 的 初始 化 只 包含 了 三 句 代码 ， 其 中 前 两 句 只 用 于 属性 
的 验证 ， 比 如 connectionFacory 或 者 destination 等 属性 是 否 为 空 等 ， 而 
真正 用 于 初始 化 的 操作 委托 在 initialize() 中 执行 。 


public void initialize() throws JmsException 1 
try { 
/WlifecycleMonitor 用 于 控制 生命 周期 的 同步 处 理 
synchronized (this.lifecycleMonitor) 1 
this.active = true; 
this.lifecycleMonitor.notifyAIll(); 
j 
dolInitialize(); 
j 
catch (JMSException ex) 1 


synchronized (this.sharedConnectionMonitor) 1 


ConnectionFactoryUtils.releaseConnection(this.sharedConnection, 
getConnectionFactory(), this.autoStartup); 
this.sharedConnection - null; 


} 


throw convertJmsAccessException(ex); 


j 
protected void dolnitialize() throws JMSException 1 
synchronized (this.lifecycleMonitor) 1 
for (int i = 0; i < this.concurrentConsumers; i++) ( 


scheduleNewInvoker(); 


这 里 用 到 了 concurrentConsumers 属 性 ， 网 络 中 对 此 属性 用 法 的 说 
明 如 下 。 
消息 监听 器 允许 创建 多 个 Session 和 MessageConsumer 来 接收 消 
息 。 具 体 的 个 数 由 concurrentConsumers 属 性 指定 。 需 要 注意 的 是 ， 应 
该 只 是 在 Destination 为 Queue 的 时 候 才 使 用 多 个 MessageConsumer 
(Queue 中 的 一 个 消息 只 能 被 一 个 Consumer 接收 ) ， 里 然 使 用 多 个 
MessageConsumer 会 提高 消息 处 理 的 性 能 ， 但 是 消息 处 理 的 顺序 却 得 
不 到 保证 。 消 息 被 接收 的 顺序 仍然 是 消息 发 送 时 的 顺序 ， 但 是 由 于 消 
息 可 能 会 被 并 发 处 理 ， 因 此 消息 处 理 的 顺序 可 能 和 消息 发 送 的 顺序 不 
同 。 此 外 ， 不 应 该 在 Destination 为 Topic 的 时 候 使 用 多 个 
MessageConsumer， 因 为 多 个 MessageConsumer 会 接收 到 同样 的 消息 。 
对 于 具体 的 实现 逻辑 我 们 只 能 继续 查看 源码 : 
private void scheduleNewInvoker() 1 
AsyncMessageListenerInvoker invoker = new 
AsyncMessageListenerInvoker(); 
if (rescheduleTaskIfNecessary(invoker)) { 
// This should always be true, since we're only calling this when active. 
this.scheduledInvokers.add(invoker); 
i 
} 
protected final boolean rescheduleTaskIfNecessary(Object task) { 
if (this.running) { 
try { 
doRescheduleTask(task); 
} 
catch (RuntimeException ex) { 


logRejectedTask(task, ex); 


this.pausedTasks.add(task); 

} 
return true; 

} 

else if (this.active) { 
this.pausedTasks.add(task); 
return true; 

} 

else { 


return false; 


} 

protected void doRescheduleTask(Object task) { 

this.taskExecutor.execute((Runnable) task); 

} 

分 析 源 码 得 知 ， 根 据 concurrentConsumers 数 量 建立 了 对 应 数量 的 
线程 ， 即 使 读者 不 了 解 线程 池 的 使 用 ， 至 少 根 据 以 上 代码 可 以 推断 出 
doRescheduleTask 拯 | 数 其 实 是 在 开启 一 个 线程 执行 Runnable。 我 们 反 追 
踪 这 个 传 入 的 参数 ， 可 以 看 到 这 个 参数 其 实 是 
AsyncMessageListenerInvoker 类 型 实例 。 因 此 我 们 可 以 推断 ，Spring 根 
据 concurrentConsumers 数 量 建立 了 对 应 数量 的 线程 ， 而 每 个 线程 都 作 
为 一 个 独立 的 接收 者 在 循环 接收 消息 。 

于 是 我 们 把 所 有 的 焦点 转向 AsyncMessageListenerInvoker 这 个 类 的 
实现 ， 由 于 它 是 作为 一 个 Runnable 角 色 去 执行 ， 所 以 对 以 这 个 类 的 分 
析 从 run 方 法 开始 。 

public void run() 1 

/并 发 控制 


synchronized (lifecycleMonitor) 1 
activeInvokerCount++; 
lifecycleMonitor.notifyAIl(); 
j 
boolean messageReceived - false; 
try { 
// 根 据 每 个 任务 设置 的 最 大 处 理 消息 数量 而 作 不 同 处 理 
// 小 于 0 默认 为 无 限制 ， 一 直接 收 消息 
if (maxMessagesPerTask < 0) { 
messageReceived = executeOngoingLoop(); 
j 
else { 
int messageCount = 0; 
/消息 数量 控制 ， 一 旦 超出 数量 则 停止 循环 
while (isRunning() && messageCount < 
maxMessagesPerTask) { 
messageReceived - (invokeListener() || messageReceived); 


messageCount++; 


} 
catch (Throwable ex) { 
/清理 操作 ， 包 括 关 闭 session 等 
clearResources(); 
if (!this.lastMessageSucceeded) ( 
// We failed more than once in a row - sleep for recovery 


interval 


// even before first recovery attempt. 
sleepInbetweenRecoveryAttempts(); 
} 
this.lastMessageSucceeded = false; 
boolean alreadyRecovered = false; 
synchronized (recoveryMonitor) { 
if (this.lastRecoveryMarker == currentRecoveryMarker) { 
handleListenerSetupFailure(ex, false); 
recoverA fterListenerSetupFailure(); 
currentRecoveryMarker = new Object(); 
} 
else { 


alreadyRecovered = true; 


} 
if (alreadyRecovered) { 


handleListenerSetupFailure(ex, true); 


} 
finally { 
synchronized (lifecycleMonitor) { 
decreaseActiveInvokerCount(); 
lifecycleMonitor.notify AIl(); 
j 
if (ImessageReceived) { 


this.idleTaskExecutionCount++; 


else { 
this.idleTaskExecutionCount = 0; 
j 
synchronized (lifecycleMonitor) ( 
if (IshouldRescheduleInvoker(this.idleTaskExecutionCount) || 
!reschedule 
TaskIfNecessary(this)) { 
// We're shutting down completely. 
scheduledInvokers.remove(this); 
if (logger.isDebugEnabled()) { 
logger.debug("Lowered scheduled invoker count: " + 
scheduledInvokers.size()); 
j 
lifecycleMonitor.notifyAll(); 
clearResources(); 
j 
else if (isRunning()) 1 


int nonPausedConsumers = getScheduledConsumerCount() 


getPausedTaskCount(); 

if (nonPausedConsumers < 1) { 
logger.error("All scheduled consumers have been paused, 
probably due to tasks having been rejected. " + 
"Check your thread pool configuration! Manual 


recovery necessary through a start() call."); 


else if (nonPausedConsumers < getConcurrentConsumers()) 


logger.warn(" Number of scheduled consumers has 
dropped 

below concurrentConsumers limit, probably " + 

"due to tasks having been rejected. Check your 

thread pool configuration! Automatic recovery " + 


"to be triggered by remaining consumers."); 


} 
以 上 函数 中 主要 根据 变量 maxMessagesPerTask 的 值 来 分 为 不 同 的 


情况 处 理 ， 当 然 ， 函 数 中 还 使 用 了 大 量 的 代码 处 理 异 常 机 制 的 数据 维 
护 ， 但 是 我 相信 大 家 跟 我 一 样 更 加 关注 程序 的 正常 流程 是 如 何 处 理 
的 。 

其 实 核心 的 处 理 就 是 调用 invokeListener 来 接收 消息 并 激活 消息 监 
听 器 ， 但 是 之 所 以 两 种 情况 分 开 处 理 ， 正 是 考虑 到 在 无 限制 循环 接收 
消息 的 情况 下 ， 用 户 可 以 通过 设置 标志 位 running 来 控制 消息 接收 的 暂 
停 与 恢复 ， 并 维护 当前 消息 监听 器 的 数量 。 

private boolean executeOngoingLoop() throws JMSException 1 

boolean messageReceived - false; 

boolean active - true; 

while (active) 1 

synchronized (lifecycleMonitor) { 


boolean interrupted = false; 


boolean wasWaiting = false; 


/如 果 当 前 任务 已 经 处 于 激活 状态 但 是 却 给 了 暂时 终止 的 


3) 
少 


while ((active = isActive()) && !isRunning()) 1 
if (interrupted) 1 
throw new IllegalStateException(" Thread was interrupted 
while waiting for " + 
"a restart of the listener container, but 
container is still stopped"); 
j 
if (!wasWaiting) { 
/如 果 并 非 处 于 等 待 状态 则 说 明 是 第 一 次 执行 ， 需 要 
将 激活 任务 数量 减少 
decreaseActiveInvokerCount(); 
j 
/开始 进入 等 待 状态 ， 等 待 任务 的 恢复 命令 
wasWaiting = true; 
try 1 
/通过 wait 等 待 ， 也 就 是 等 待 notify 或 者 notifyAll 
lifecycleMonitor.wait(); 
j 
catch (InterruptedException ex) 1 
// Re-interrupt current thread, to allow other threads 
to react. 
Thread.currentThread().interrupt(); 


interrupted = true; 


j 
if (wasWaiting) { 
activeInvokerCount++; 
} 
if (scheduledInvokers.size() > maxConcurrentConsumers) { 


active = false; 


} 
/正音 处 理 流程 
if (active) 1 


messageReceived - (invokeListener() || messageReceived); 


} 
return messageReceived; 
} 
如 果 按 照 正 常 的 流程 其 实 是 不 会 进入 while 循 环 中 的 ， 而 是 直接 进 
入 函数 invokeListener0 来 接收 消息 并 激活 监听 器 ， 但 是 ， 我 们 不 可 能 
让 循环 一 直 持 续 下 去 ， 我 们 要 考虑 到 暂停 线程 或 者 恢复 线程 的 情况 ， 
这 时 ，isRunningO 国 数 就 派 上 用 场 了 。 
isRunning() 用 来 检测 标志 位 this.running 状 态 进而 判断 是 否 需要 进 
入 while 循 环 。 由 于 要 维护 当前 线程 激活 数量 ， 所 以 引入 了 wasWaiting 
变量 ， 用 来 判断 线程 是 否 处 于 等 待 状态 。 如 果 线 程 首次 进入 等 待 状 
态 ， 则 需要 减少 线程 激活 数量 计数 器 。 
当然 ， 还 有 一 个 地 方 需要 提 一 下 ， 就 是 线程 等 待 不 是 一 味 地 采用 
while 循 环 来 控制 ， 因 为 如 果 单 纯 地 采用 while 循 环 会 浪费 CPU 的 始终 周 
期 ， 给 资源 造成 巨大 的 浪费 。 这 里 ，Spring 采 用 的 是 使 用 全 局 控制 变 
量 lifecycleMonitor 的 wait() 方 法 来 暂停 线程 ， 所 以 ， 如 果 终 止 线 程 需 


再 次 恢复 的 话 ， 除 了 更 改 this.running 标 志 位 外 ， 还 需要 调用 
lifecycleMonitornotify 或 者 lifecycle Monitor.notifyAll 来 使 线程 恢复 。 
接 下 来 就 是 消息 接收 的 处 理 了 。 
private boolean invokeListener() throws JMSException { 
/初始 化 资源 包括 首次 创建 的 时 候 创 建 session 与 consumer 
initResourcesIfNecessary(); 
boolean messageReceived = receiveAndExecute(this, this.session, 
this.consumer); 
/改变 标志 位 ， 信 息 成 功 处 理 
this.lastMessageSucceeded = true; 
return messageReceived; 
j 
protected boolean receiveAndExecute(Object invoker, Session session, 
MessageConsumer 
consumer) 
throws JMSException { 
if (this.transactionManager != null) 1 
// Execute receive within transaction. 
TransactionStatus status = 
this.transactionManager.getTransaction(this. 
transactionDefinition); 
boolean messageReceived; 
try { 
messageReceived = doReceiveAndExecute(invoker, session, 
consumer, status); 
} 
catch (JMSException ex) { 


rollbackOnException(status, ex); 
throw ex; 
} 
catch (RuntimeException ex) { 
rollbackOnException(status, ex); 
throw ex; 
} 
catch (Error err) { 
rollbackOnException(status, err); 
throw err; 
} 
this.transactionManager.commit(status); 
return messageReceived; 
} 
else { 
// Execute receive outside of transaction. 


return doReceiveAndExecute(invoker, session, consumer, null); 


} 

在 介绍 消息 监听 器 容器 的 分 类 时 ， 已 介绍 了 
DefaultMessageListenerContainer 消息 监听 器 容器 建立 在 
SimpleMessageListenerContainer 容 器 之 上 ， 添 加 了 对 事务 的 支持 ， 那 
么 此 时 ， 事 务 特 性 的 实现 已 经 开始 了 。 如 果 用 户 配置 了 
this.transactionManager ， 也 就 是 配置 了 事务 ， 那 么 ， 消 息 的 接收 会 被 
控制 在 事务 之 内 ， 一 旦 出 现任 何 异 常 都 会 被 回 滚 ， 而 回 滚 操作 也 会 交 
由 事务 管理 器 统一 处 理 ， 比 如 this.transactionManager.rollback(status)。 


doReceiveAndExecute 包含 了 整个 消息 的 接收 处 理 过 程 ， 由 于 参 杂 
着 事务 ， 所 以 并 没有 复 用 模板 中 的 方法 。 
protected boolean doReceiveAndExecute( 
Object invoker, Session session, MessageConsumer consumer, 
TransactionStatus 
status) 
throws JMSException { 
Connection conToClose = null; 
Session sessionToClose = null; 
MessageConsumer consumerToClose = null; 
try { 
Session session ToUse = session; 
boolean transactional - false; 
if (sessionToUse == null) { 
session ToUse = 
ConnectionFactoryUtils.doGetTransactionalSession( 
getConnectionFactory(), this.transactionalResourceFactory, 
true); 
transactional = (sessionToUse !- null); 
j 
if (sessionToUse == null) { 
Connection conToUse; 
if (sharedConnectionEnabled()) 1 
conToUse = getSharedConnection(); 
j 
else { 


conToUse = createConnection(); 


conToClose = conToUse; 
conToUse.start(); 


} 


session ToUse = createSession(conToUse); 
session ToClose = sessionToUse; 
} 
MessageConsumer consumerToUse = consumer; 
if (consumerToUse == null) { 
consumerToUse = createListenerConsumer(sessionToUse); 
consumerToClose = consumerToUse; 
} 
/接收 消息 
Message message = receiveMessage(consumerToUse); 
if (message != null) 1 
if (logger.isDebugEnabled()) { 
logger.debug(" Received message of type [" + 
message.getClass() * 
"] from consumer [" + 
consumerToUse + "] of " + (transactional ? "transactional 
" 177) + "session [" + 
sessionToUse + "]"); 
} 
// 模 板 方 法 ， 当 消息 接收 且 在 未 处 理 前 给 子 类 机 会 做 相 
应 处 理 ， 当 期 空 实现 
messageReceived(invoker, sessionToUse); 
boolean exposeResource = (!transactional && 


isExposeListenerSession() && 


!TIransactionSynchronizationManager.hasResource 
(getConnection 


Factory())); 
if (exposeResource) 1 
TransactionSynchronizationManager.bindResource( 


getConnectionFactory(), new LocallyExposedJms 
Resource 


Holder(session ToUse)); 
j 
try 1 
/激活 监听 器 
doExecuteListener(sessionToUse, message); 
j 
catch (Throwable ex) 1 
if (status != null) 1 
if (logger.isDebugEnabled()) 1 


logger.debug(" Rolling back transaction because of listener exception 
thrown: " + ex); 


} 
status.setRollbackOnly(); 
} 
handleListenerException(ex); 
// Rethrow JMSException to indicate an infrastructure problem 
// that may have to trigger recovery... 
if (ex instanceof JMSException) { 
throw (JMSException) ex; 


j 
finally { 
if (exposeResource) 1 
TransactionSynchronizationManager.unbindResource&nbsp; 
(getConnectionFactory()); 
} 
} 
// Indicate that a message has been received. 
return true; 
} 
else { 
if (logger.isTraceEnabled()) { 
logger.trace("Consumer [" + consumerToUse + "] of " + (transactional 
? "transactional " : "") + "session [" + session ToUse + "| did not receive a 
message"); 
j 
/接收 到 空 消 息 的 处 理 
noMessageReceived(invoker, session ToUse); 
// Nevertheless call commit, in order to reset the transaction timeout 
(if&nbsp;any). 
// However, don't do this on Tibco since this may lead to a 
deadlock&nbsp;there. 
if (shouldCommitAfterNoMessageReceived(session ToUse)) 1 
commitIfNecessary(sessionToUse, message); 
j 
// Indicate that no message has been received. 


return false; 


j 
finally { 
JmsUtils.closeMessageConsumer(consumerToClose); 
JmsUtils.closeSession(sessionToClose); 
ConnectionFactoryUtils.releaseConnection(conToClose, 
getConnectionFactory(),&nbsp;true); 
} 
} 
FERRI WURA, BEREHAT, KAZSHEN 
套路 ， 而 我 们 最 天 心 的 就 是 监听 器 的 激活 处 理 。 
protected void doExecuteListener(Session session, Message message) 
throws JMSException { 
if (tisAcceptMessagesWhileStopping() && !isRunning()) { 
if (logger.isWarnEnabled()) { 
logger.warn("Rejecting received message because of the listener 
container " + "having been stopped in the meantime: " + message); 
j 
rollbackIfNecessary(session); 
throw new MessageRejectedWhileStoppingException(); 
j 
try { 
invokeListener(session, message); 
j 
catch (JMSException ex) 1 
rollbackOnExceptionIf Necessary(session, ex); 


throw ex; 


j 
catch (RuntimeException ex) 1 
rollbackOnExceptionIf Necessary(session, ex); 
throw ex; 
j 
catch (Error err) 1 
rollbackOnExceptionIf Necessary(session, err); 
throw err; 
j 
commitIfNecessary(session, message); 
j 
protected void invokeListener(Session session, Message message) 
throws JMSException { 
Object listener = getMessageListener(); 
if (listener instanceof SessionAwareMessageListener) { 
doInvokeListener((SessionAwareMessageListener) listener, 
session, message); 
} 
else if (listener instanceof MessageListener) { 
doInvokeListener((MessageListener) listener, message); 
} 
else if (listener != null) { 
throw new IllegalArgumentException( "Only MessageListener and 
SessionAwareMessageListener supported: " + listener); 
} 


else { 


throw new IllegalStateException("No message listener specified - see 

property 'messageListener'"); 
i 

} 

protected void doInvokeListener(MessageListener listener, Message 
message) throws JMSException { 

listener.onMessage(message); 

} 

通过 层 层 调用 ， 最 终 提取 监听 器 并 使 用 
listener.onMessage(message) 激 活 了 监听 器 ， 也 就 是 激活 了 用 户 自 定义 
的 监听 器 逻辑 。 这 里 还 有 一 句 重 要 的 代码 很 容易 被 忽略 掉 ， 
commitIfNecessary(session, message)， 完 成 的 功能 是 session.commit()。 
完成 消息 服务 的 事务 提交 ， 涉 及 两 个 事务 ， 我 们 常 说 的 
DefaultMessageListenerContainer 增 加 了 事务 的 支持 ， 是 通用 的 事务 ， 
也 就 是 说 我 们 在 消息 接收 过 程 中 如 果 产 生 其 他 操作 ， 比 如 向 数据 库 中 
插入 数据 ， 一 旦 出 现 异常 时 就 需要 全 部 回 滚 ， 包 括 回 滚 插入 数据 库 中 
的 数据 。 但 是 ， 除 了 我 们 常 说 的 事务 之 外 ， 对 于 消息 本 身 还 有 一 个 事 
务 ， 当 接收 一 个 消息 的 时 候 ， 必 须 使 用 事务 提交 的 方式 ， 这 是 在 告诉 
消息 服务 器 本 地 已 经 正常 接收 消息 ， 消 息 服务 器 接收 到 本 地 的 事务 提 
交 后 便 可 以 将 此 消息 删除 ， 否 则 ， 当 前 消息 会 被 其 他 接收 者 重新 接 
收 。 
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器 的 基本 实现 、 默 认 标 签 的 解析 、 自 定义 标签 的 解析 、bean 的 加 载 、 
容器 的 功能 扩展 、AOP、 数 据 库 连 接 JDBC、 整 合 MyBatis、 事 务 、 
SpringMVC、 远程 服务 、Spring 消 息 服务 等 内 容 。 

本 书 不 仅 介 绍 了 使 用 Spring 框架 开发 项 目 必 须 掌握 的 核心 概念 ， 
还 指导 读者 如 何 使 用 Spring 框架 编写 企业 级 应 用 ， 并 针对 在 编写 代码 
的 过 程 中 如 何 优化 代码 、 如 何 使 得 代码 高 效 给 出 切实 可 行 的 建议 ， 从 
而 帮助 读者 全 面 提 升 实战 能 力 。 

本 书 语言 简洁 ， 示 例 丰富 ， 可 帮助 读者 迅速 掌握 使 用 Spring 进行 
开发 所 需 的 各 种 技能 。 本 书 适合 于 已 具有 一 定 Java 编 程 基 础 的 读者 ， 
以 及 在 Java 平 台 下 进行 各 类 软件 开发 的 开发 人 员 、 测 试 人 员 等 。 
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